Quels sont les pires noms de variables que vous avez déjà vus ?

[Hinault Romaric]

Quels sont les pires noms de variables que vous avez déjà vus ?
Un développeur identifie les deux plus mauvais noms de variables couramment utilisés dans le code


Un problème auquel est continuellement confronté le développeur dans son activité est l’attribution des noms aux variables.

Afin de faciliter la lisibilité et la compréhension du code, le programmeur opte le plus souvent pour des variables suffisamment descriptives ou se reporte à des conventions de nommage.

ANDY Lester, un développeur senior se penche dans un billet de blog sur les noms attribués aux variables et présente selon lui les deux pires noms qui sont constamment utilisés par les développeurs pour qualifier les variables.

La pire dénomination qu’un développeur peut donner à une variable est selon Lester le nom « data ».

Code php :

1
2
3
 
$data = read_record();
print "ID = ", $data["CUSTOMER_ID"];

« Bien sûr il y a des données ! C’est ce que contiennent les variables » écrit Lester, qui ironise par la suite. « C’est comme si vous emballez vos biens dans des cartons de déménagement et vous les étiquetez le carton des matières ».

Pour ANDY Lester, les noms des variables doivent dire quel type de données est manipulé.

En seconde position, l’utilisation des chiffres pour distinguer les variables. Exemple : data2.

Code php :

1
2
3
4
5
6
7
8
9
 
$total = $price * $qty;
$total2 = $total - $discount;
$total2 += $total2 * $taxrate;
 
$total3 = $purchase_order_value + $available_credit;
if ( $total2 < $total3 ) {
    print "You can't afford this order.";
}

N’importe quelle variable qui s’appuie sur un chiffre pour se distinguer d’une autre doit être immédiatement renommée. Le véritable assassin dans le code ci-dessus selon Lester est la ligne « if ($ total2 <$ total3) » qui obliger à remonter plus haut pour l’interpréter.

Ce ne sont là que deux exemples sur de mauvais noms de variables qui sont utilisés par les développeurs.



Source : Blog ANDY Lester


Et vous ?

Avez-vous déjà utilisé ces noms pour vos variables ?

Quels autres pires noms de variables avez-vous déjà vus ?

[elmcherqui]

On a tous nommé nos variables quand on a debuté le dev jusqu'a ce qu'on comprenne que ce n'etait pas comme les maths ( a , b , c , x ... ) et pour vraiment comprendre les degats de ce genre de nomoclature je conseil

http://www.pearson.fr/livre/?GCOI=27440100643800

version francaise de clean code

Une Perle , et je vous assure qu'apres avoir lu le livre votre vision des variable aura changé

[jv-boy]

Avez-vous déjà utilisé ces noms pour vos variables ?

Ouais quand j'etais debutant, en bts alternance. Je vais debugger du code VBA et ajouter des fonctionnalites. Comme je voyait des variables genre total1, total 2 ben j'enchainais avec total3 etc ...

A l'epoque je croyais que c'etait un truc bien, etant donnee que mon maitre de stage le faisait !

Quels autres pires noms de variables avez-vous déjà vus ?

D'apres mes souvenirs, toujours dans cette boite:

Code :

1
2
3
4
5
6
7
8
9
10
int test;
int a;
int b;
int c;
...
int v;

int romain = 0;
String chaine;

[Zack_r]

Pour ma part, un ancien développeur nommer toutes ces variables en mettant toto...

Par exemple tabtotot, toto, toto1, toto4...

L'angoisse quand j'ai vue le code la première fois...

J'espère une chose, c'est qu'il a complètement changé d'orientation professionnelle. Je sais je suis méchant, mais à cause de lui j'ai connu l'enfer !

[webpsi]

Il n'y a pas trop longtemps, j'ai vu dans un projet open source (TUIOdroid), énormément de variables d'une seule lettre, c'est vraiment une horreur quand on rencontre une variable qui s'appelle : c, d, a ...

Un petit extrait :

Code :

1
2
3
4
5
6
7
8
9
10
11
cw = getWidth();
ch = getHeight();

bx = cw/2 - backgroundImage.getWidth()/2;
by = ch/2 - backgroundImage.getHeight()/2;

Canvas c = getHolder().lockCanvas();
                
if (c != null) {
     c.drawColor(Color.WHITE);
     c.drawBitmap(backgroundImage,bx,by,null);

C'était le 1er travail que j'ai eu pour mon 1er emploi, ça m'a vraiment fait peur pour la suite, mais je suis jamais retomber sur un autre cas extrême comme celui là.

[rOnnie974]

Dans le genre pas mal, les mecs qui codent en français:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
function ChangeMagasinDirectement_chargee(response) {
        var maDonnee = JSON.parse(response.d);
        fermerPopupConfirmationChangementMagasin();
        document.location.href = maDonnee.monUrlAChanger;
    }
    
    //Pour afficher les services disponibles dans la commune
    function ObtenirInformationsServicesCommune_chargee(response) {
        var maDonnee = JSON.parse(response.d);
        
        (maDonnee.nbPointsRetrait > 0) ? $(".prRetraitDispoCommune").show() : $(".prRetraitDispoCommune").hide();
        (maDonnee.nbLivraison > 0) ? $(".livDispoCommune").show() : $(".livDispoCommune").hide();
        (maDonnee.nbDrive > 0) ?  $(".driveDispoCommune").show() :  $(".driveDispoCommune").hide();
        (maDonnee.nbRetrait > 0) ? $(".RetraitDispoCommune").show() : $(".RetraitDispoCommune").hide();
    }

http://www.expressmarche.com

[vampirella]

Les variables de quelques lettres (voire une seule) me rappelle surtout de la décompilation ...
Ceci dit, si quelqu'un est capable de coder en nommant tel que décrit par "webpsi", c'est que la personne a loupé des cours de programmation

Pour revenir sur la première critique de Lester, il arrive que je nomme une variable "data" lorsque par exemple je ne connais pas d'avance ce que je trouverais dans cette case ... en l'occurrence, lorsque je lisais des cases d'Excel. Je ne sais pas si c'est forcément justifié, mais je n'avais pas trouvé comment nommer mieux cette variable qui récupérait directement la valeur de la case.

[galerien69]

Les variables de quelques lettres (voire une seule) me rappelle surtout de la décompilation ...
Ceci dit, si quelqu'un est capable de coder en nommant tel que décrit par "webpsi", c'est que la personne a loupé des cours de programmation

ou qu'il se refere a une spec en gardant les meme denominations. Code donc un truc un peu mathematique.
Je pense quil vaut mieux expliquer son algorithme et conserver des noms de variables cours, plutot que de voir des noms de variable a rallonge.

Quant a canvas, je crois pas que ca choquera de voir un c ou un ctx se balader au sein d'une fonction. Mais la raison est differente, il s'agit d'eviter un using (jme rappele plus le mot cle), et si dans tout le projet canvas est denote par c, quel probleme cela pose-t-il?

[p1xl_01]

Un problème qui peut survenir aussi, c'est quand un développeur veut utiliser des mots anglais pour nommer ses variables mais qu'il se trompe dans le sens du mot, ou pire, quand il le comprend à l'envers! Pour ceux qui passent derrière, c'est pas évident.

[atha2]

Envoyé par webpsi

Il n'y a pas trop longtemps, j'ai vu dans un projet open source (TUIOdroid), énormément de variables d'une seule lettre, c'est vraiment une horreur quand on rencontre une variable qui s'appelle : c, d, a ...

Un petit extrait :

Code :

C'était le 1er travail que j'ai eu pour mon 1er emploi, ça m'a vraiment fait peur pour la suite, mais je suis jamais retomber sur un autre cas extrême comme celui là.

Ok le nom des variables est court (dans ton exemple) mais c'est pas trop compliqué de comprendre que x et y font référence à des coordonnées, que w et h sont la dimension, que c correspond au canvas et que b correspond au backgroundImage. Après si le code fait 300 lignes je veux bien croire que ça deviennent compliqué mais si la variable est utilisé au maximum 20 ligne après sa déclaration ça devrait aller.
De la à appeler ça un cas extrême, ça voit que tu n'est pas tombé sur du code en notation hongroise (genre arpszTableau pour un tableau de pointeurs de chaînes de caractères) qui a peut-être un intérêt dans les langages au typage implicite mais en Java ??

Envoyé par Hinault Romaric

En seconde position, l’utilisation des chiffres pour distinguer les variables. Exemple : data2.


Code php :
Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9

$total = $price * $qty; $total2 = $total - $discount; $total2 += $total2 * $taxrate; $total3 = $purchase_order_value + $available_credit; if ( $total2 < $total3 ) { print "You can't afford this order."; }


N’importe quelle variable qui s’appuie sur un chiffre pour se distinguer d’une autre doit être immédiatement renommée. Le véritable assassin dans le code ci-dessus selon Lester est la ligne « if ($ total2 <$ total3) » qui obliger à remonter plus haut pour l’interpréter.

Ce ne sont la que deux exemples sur de mauvais noms de variables qui sont utilisés par les développeurs.

Je ne suis pas sur de comprendre le problème (mais je ne suis pas un expert PHP). Ici le problème est lié au faite que l’interpréteur va mettre plus de temps à déterminer de quelle variable on parle ? Dans ce cas là, je pense que le problème vient plus de l'interpréteur que du développeur. Quand à l'utilisation de variable au nom sans réelle sémantique comme total1 et/ou total2, il arrive que certain résultat intermédiaire de calcul n'ai pas vraiment sens. Auquel cas appeler une variable "dd" (ou toto) ne me gène absolument pas.

Dans l'ensemble j'avoue que j'ai tendance à utiliser de nom de variable à rallonge du type trucQuiFaitMachineDansTelContext c'est long mais au moins on comprend à quoi elle sert et avec les IDE, la longueur de la variable n'importe plus vraiment.

[djinneo]

Pour les boucles, l'emploi d'itérateurs nommés avec une seule lettre (au hasard "i", "j", "k") relève quasi de la convention d'écriture.

Je m'étais donc fait "plaisir" en les bapisant "irene", "julie" et "katia" -ce qui était en même temps, un clin d'oeil à des stagiaires de la boîte.

Mais j'ai trouvé ça bcp moins fun quand ma hiérarchie a inspecté mon code

[befalimpertinent]

Je rejoins ce qui disent que les pires sont les variables d'un seul caractère. J'ai même parfois vu des choses du type:

Code :

1
2
int a;//age du capitaine

Mais Bo*$€|_ ! Pourquoi ne pas avoir écrit:

Code :

1
2
int age_du_capitaine;

[webpsi]

Dans le projet que j'ai cité au dessus, il y avais 2 problème : le même que le "problème data" de l'article, ex : h c'est la hauteur, mais de quoi ???, il faut donc remonter le code jusqu'à trouver ce que l'on veux.

L'autre problème est que l'on ne sait pas l'utilité de la variable, le canvas à été utiliser pour afficher du texte informatif sur une image, comment on sait que "c" est censé afficher si le serveur est en ligne et notre adresse IP ?!?

C'était surtout utilisé dans des fonctions, ce qui peut énormément géner quand on utilise une fonction et que l'on voit 2 lettres comme argument, on est obliger de lire le contenu de la fonction pour savoir quoi mettre.

Même si je sais qu'il y a pire, je n'appelle pas ça un code fait par un informaticien (ce qui n'est peut être pas le cas pour ce projet).

PS : dans ce projet j'ai aussi vu du copier-coller de fonctions statiques

[Traroth2]

Ah oui, les anglicismes approximatifs, c'est assez marrant. Ici, on a un type qui a appelé des classes "Expeditor" et "Receptor", pour faire anglais.

[PatteDePoule]

J'ai déjà vu une méthode "ObtenirUnTruc" et une autre "EnregistrerUnTruc".

Ça ne pouvait pas être mieux résumé...

[-marq]

Perso le pire truc que j'ai vu, c'est la variable qui s'appelle objet

bon Ok c’était un objet, mais fallait retrouver le type d'objet après


Il y aussi ceux qui laissent arg1, arg2 générés par défaut.

ca peut devenir dur à lire.

[p1xl_01]

Pour illustrer ce que j'ai dit plus haut, j'ai déjà eu affaire à un booléen isRelevant qui était à false pour définir une donnée importante.

[sinople]

Le plus important, selon mon avis, est d'avoir une convention commune et respectée sur le nommage des variables pour l'ensemble de la team, société travaillant sur le projet.

Après qu'on utilise i ou indice pour une boucle, qu'on utilise des termes français dans le nom c'est secondaire du moment que tout le monde fasse pareil (et le comprenne).

[Freem]

Mon avis...

C'est que déjà, la lettre du type des variable, ça ne sert que dans les cas ou l'on à au moins 2 problèmes:
_ un langage non typé (ou faiblement), ou une erreur de type risque de générer des erreurs d'exécution. En C++, j'ai autre chose à faire que de coller des ippc devant un tableau d'entiers constants... (surtout qu'en fait j'utilise des vecteurs dans ce cas ^^)
_ un code a rallonge. Plus un code est long, plus il a de variable. Plus le nom de celles-ci est important. Et un code long est souvent synonyme d'une fonction qui possède... plus d'une fonction. Dans ce cas, autant les diviser en plusieurs fonctions.

Personnellement, j'ai plus tendance à diviser mon code en petites classes, qui chacune sont très spécialisées. La conséquence, c'est qu'elles possèdent peu de variables, (que malgré tout je m'acharne à nommer de façon pas trop stupide au maximum) et peu de méthodes longues.

Par contre, si je commençait à m'amuser à mettre le type avant, je me retrouverait avec des trucs du style:
vumChildren pour exprimer ceci: std::vector<std::unique_ptr<Menu>> children. Lisible? Je trouve pas, sachant que ma classe ne possède de toute façon que 4 ou 5 membres maxi, qu'un seul est un vector, et que du coup, children, qui est le pluriel de child, montre bien ce point.
Dans ce bazard, en plus, le m de Menu ne veux rien dire, puisque dès lors que l'on utilise le polymorphisme, ce n'est pas forcément un menu qui y est stocké, mais un de ses enfants... Design pattern composite dans mon cas.

La notation hongroise, je la trouvais fun à une époque, mais je n'ai jamais réussi à me résoudre a taper une variable de plus de 15 caractères de long.

Ok, les noms explicite, c'est bien. Mais les noms longs ne sont pas explicites. Je préfère lire un code aux variables obfusquées mais aux fonctions bien encapsulées plutôt qu'un code de 5km aux noms à rallonge qui décrivent trop ce qu'elles font.

En fait, mon approche m'amène même a remettre en cause le surplus de commentaires. Quand une fonction porte bien son nom, ça vaut un commentaire, et c'est même supérieur, parce que le comm' est pas forcément à jour. Et quand un bout de code mérite un commentaire, pourquoi ne pas le mettre dans une fonction? Pour la perf'? D'abord avoir un truc lisible et qui marche, avant de voir la perf... Et au pire, en C++ il y a le mot clé "inline"... Dans d'autres langages, il n'est pas nécessaire, le compilo fait tout.

Bref, ce type de "ma façon de coder c'est la plus belle et la plus explicite" j'ai tendance à ne jamais être d'accord avec. Certes, c'est ce qui est enseigné à l'école. Mais je n'ai encore eu aucun prof/collègue qui sache ce qu'est un design pattern, que ce soit ceux du GoF ou les patterns GRASP.
Pour ces second, on parle pourtant des fondements de la POO...

Je veux bien admettre me planter de tout en tout, mais avant, j'aimerai que l'on me montre un code qui soit réellement illisible à cause de la petite taille des variables. Et qu'il soit effectivement impossible à diviser en fonctions dont le nom, nettement plus important, rende le tout lisible.

Au passage, ma convention perso, pour les variables c'est :
"m_" avant les membres d'une classe.
"s_" avant les variables statiques.
"sm_" avant les variables statiques d'une classe. (encore que j'admette qu'il m'arrive de ne pas mettre le 'm' parce qu'il est rare que je mette une variable statique globale. Et dans ce cas, c'est systématiquement un singleton, donc une classe suffisamment particulière pour que la doc qui accompagne mon code explique le problème)
"" avant les variables locales.
Jusqu'ici, ça m'a toujours donné des codes lisibles et sans variables surchargées.

[edit]
Au sujet du "vumChildren" je tiens a préciser que je peux avoir plusieurs classes commençant par la même lettre, pour empirer la chose.
Et que je manipule plus souvent des objets que des variables de type standard limite. Ben oui, c'est l'intérêt d'avoir des classes spécialisée, d'éviter de taffer sois-même.

Et sinon, dans mes noms favoris, je dois avoir "it" pour les iterator, tmp quand je sais pas comment nommer une variable qui sert juste de tampon, et les habituelles collections i j k ...

[tonnebrre]

le pire nom de variable que j'ai utilisé et "nbr" ça fait mal au cœur de voir ce genre de noms