Discussion :

[zeyr2mejetrem]

...et avec les langages dynamiques ne nécessitant pas de déclaration des variables avant leur initialisation, utiliser par erreur « facturé » à un endroit du code et « facture » à un autre pour désigner la même variable est facile et est la garantie d'une joyeuse séance de débogage.

A l'œil il est plus facile de repérer une erreur typographique comme l'oubli ou l'ajout d'une lettre qu'une erreur d'accent.

C'est marrant aussi quand on travaille avec des développeurs espagnols qui se trompent dans les accents de variable ou déclarent des variables avec des noms espagnols.
On se retouve avec des expressions du genre:

añoFacturacìon = facturationPériodique/N;

Super sympa !!

[Invité]

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

Si on utilise ce genre de critère pour juger de la qualité d'un programme, il va falloir mettre à la poubelle pas mal de code qui a fait ses preuves. Je ne sais pas si vous avez vu le code de gcc, de diverses implémentations d'Unix, ou de ses librairies, de librairies assez pointues. En général, c'est un florilège de "mauvaises pratiques" décrites sur ce fil. A l'inverse, on a tous, je pense, vu ces grands projets qui font le désespoir des utilisateurs et la fortune des SSII, avec des conventions de nommage ultra détaillées, qui respectent toutes les bonnes pratiques, et pourtant...

Sérieusement, "data" n'est un mauvais nom que quand on l'emploie à tort et à travers. Dans une fonction qui traite des données, selon des paramètres (une classe encapsulant une requête, ou un conteneur, ou quelque chose du genre) appeler "data" les données, c'est parfaitement légitime.

Préciser davantage, c'est souvent dangereux. On dit toujours que les commentaires peuvent ne plus être à jour, c'est pareil pour les noms de variables. Une variable intitulée intSommeDesTarifsDeLaFacture sera un cauchemar de débogage le jour où certains tarifs étant des remises, la "somme" n'en sera plus une, où pour prendre en compte des problèmes d'arrondi, elle contiendra des valeurs flottantes, et où "la" facture sera devenue une "liasse", qui mélange plusieurs factures, ou deviendra partielle.

Par ailleurs, un nom long n'est pas forcément plus précis qu'un nom court. N'importe quel développeur ayant lu du code (ou fait des maths) sait que i, j, et k sont des compteurs de boucle, les appeler "compteur" ou quelque chose du genre ne précise rien (pareil quand on remplace x par abscisse, ou z par hauteur...)

Le code "mandel()" posté plus haut dans ce fil est un excellent exemple. Si on sait ce que représente ce genre de fractale, alors il est parfaitement clair. Si on ne sait pas, il faut lire un manuel, mais il ne faut pas espérer que ces choses (ici des questions de convergence dans le plan complexe) deviendront claires parce qu'on renommera px, py, ou xx (en quoi d'ailleurs?).

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

Personnellement, j'utilise presque toujours des noms courts pour les variables locales, et je préfère des conventions à des noms "explicites" qui changent tout le temps. Généralement, mes compteurs s'appellent i,j,k etc... (mais jamais x, y et z). Mes tailles s'appellent toutes sz, ou nb, avec parfois une ou deux lettres pour éviter la confusion. Mes noms de fonctions ou de classes sont généralement plus explicites, mais rarement longs. En général, si j'ai un calcul à faire, je préfère l'appeler calcul() que calcul_de_ la_somme_ponderee(), simplement parce qu'il y a neuf chances sur dix que le "meilleur" nom devienne caduc d'ici la prochaine version du programme.

Les gens avec qui je travaille utilisent généralement d'autres conventions, quand je regarde leur code, je m'y adapte, mais le fait qu'on ait des "styles compatibles" est pour moi un critère de recrutement.

Dans de petites équipes stables, le fait d'avoir des styles compatibles mais différents présente un avantage supplémentaire : on sait, en voyant un bout de code, d'où il provient.

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

Ce que j'aime le moins, ce sont : les classes où tous les noms se ressemblent, quelque chose comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
class voVector {
   vector _voVector;
   voVector(voVector & vovector): _voVector(vovector);
}

Les noms compliqués qui ne sont précis que dans la tête de celui qui les a imaginés (et quand on les lit, on se dit qu'on n'aimerait pas y être, dans sa tête), des noms de classe comme "variableModaleMultivariee" (ça ne veut rien dire), ou "CompteurdeBoucleIterative" (tout ca pour dire "i"!)

Les noms qui disent l'inverse de ce qu'ils sont censés dire, soit parce que leur auteur maîtrise mal la langue (j'ai un jour vu quelqu'un qui confondait Get et Set... ca fait du code assez curieux), soit parce que le code a évolué mais pas le nom.

Le jargon technique, dans le meilleur des cas ce n'est lisible que par ceux qui ont lu les même livres que le développeur, dans le pire (et hélas le plus fréquent), ce n'est lisible par personne, parce que le développeur l'emploie de travers.

Francois

[Freem]

Et quand on voit l'amour des gens pour les accents...

Je serai "pour" les variables accentuées le jour ou ceux qui revendiquent leur utilisation n'auront plus besoin de correcteur orthographique pour écrire un mail de 5 lignes sans fautes!
Bon, j'exagère un peu, mais il faut l'admettre: l'anglais est une langue plus simple que le français par exemple, et plus concise. En plus, elle offre une concision et une pauvreté sémantique qui la rend plus rapidement lisible. (pour la remarque précédente, je dois reconnaître apprécier l'utilisation du correcteur inclus dans mon navigateur, bien que ce soit le seul endroit ou je l'utilise, vu que je ne prends pas le temps de me relire correctement sur le net)
Et il faut aussi admettre: on voit nombre de documents rédigés par des gens hautement qualifiés qui sont bourrés de fautes de français.
Si quelqu'un écrit:
"if(contigües) doSomething(); " qui me dis qu'un dev non attentionné derrière ne fera pas: "if(contigues)" à la place? Et certains langages ne nécessitant pas de déclaration préalable des variables, je laisse imaginer la cata en débogage dans un code de quelques dizaines de lignes!

Non non restons avec l'anglais, sans accents, avec moins de richesse dans la nuance que les autres langues. C'est très efficace pour la technique. (pour le reste, très discutable et selon les goûts)

Ca dépend des cas.
Il m'arrive régulièrement de manipuler des données dont je dois convertir le type. Cas typique :
Je reçois une valeur numérique dans une String (stockée de cette manière en base de données, pas ma faute, toussa toussa) et pour pouvoir l'exploiter, je crée une variable temporaire préfixée par dbl ou int, suivie du nom de la variable d'origine. Cela me permet de savoir que je manipule l'information d'origine, mais au bon format.
Et de même dans l'autre sens, quand je reçois un entier et que je dois le convertir en String, je préfixe par str histoire de m'y retrouver.

Dans ce cas, pourquoi ne pas créer un getter (ou un setter) qui permette de séparer la conversion du traitement? Ce serait bien plus logique, et permettrait d'éviter de dupliquer le code quand tu dois refaire l'opération.
Et si ce qui t'ennuies est la perte d'efficacité liée à l'appel d'une fonction supplémentaire, il suffit de la rendre inline (ou l'équivalent, je suppose que C++ n'es pas le seul à proposer cette optimisation). Pour les constructeurs/destructeurs supplémentaires appelés, il suffit d'utiliser le passage par référence au lieu de valeur.

[ManusDei]

En partiel de C, pris d'un gros délire, j'ai craqué.

J'ai appelé une sous-fonction Tartiflette, et les variables lardons, oignons, reblochon etc...

J'ai eu une autre fonction Cassoulet, et une fonction Couscous.

Bizarrement, je me suis retrouvé au rattrapage, et un prof m'a gentiment expliqué lors de la consultation des copies que non, c'était vraiment pas possible de corriger ces choses là.

PS : Je n'ai pas recommencé, et je ne recommencerais pas. Donc pas taper

[Charvalos]

J'ai appelé une sous-fonction Tartiflette, et les variables lardons, oignons, reblochon etc...

J'ai eu une autre fonction Cassoulet, et une fonction Couscous.

Il était quelle heure ? Midi ? Ton ventre criait famine ?

[ManusDei]

Il était quelle heure ? Midi ? Ton ventre criait famine ?

C'est un peu vieux, donc je m'en souviens plus. Mais je crois pas que j'avais faim (je suis prévoyant dans ce genre de situation).

[cdtkoenig]

Moi j'ai connu un développeur qui utilisait des variables du genre $cocoboy et $cocogirl ... C'est maintenant devenu un mythe dans le coin, une "légende urbaine" ...

[AdmChiMay]

J'ai pas pu résister...

Moi j'ai connu un développeur qui utilisait des variables du genre $cocoboy et $cocogirl ... ...

Donc

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if $cocogirl = cocorico($cocoboy) then xxx

Désolé

[marton92]

J'en ai eu des pas mal. LNCCGARA (Hélène Ségara) pour le code garantie. CHT pour un job de suppression, et CHU pour la restauration, ça s'invente pas.

[SurferIX]

J'ai pas pu résister...

Donc

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if $cocogirl = cocorico($cocoboy) then xxx

Désolé

Genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
try {
}
catch( Exception $pokemon) {
  // $pokemon => Attrapez les tous !
}

[barbouille]

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

Boudiou c'était donc toi !!

En ce qui me concerne, le pire a été pendant une mission "an 2000" pour certifier un programme cobol (qui a dit "le vieux") dont tous les noms de variables et de paragraphes étaient des prénoms de filles.

Ben pour trouver que Justine et Agathe étaient des dates, mais pas Christine ni Gisèle ça ne fut point simple du tout.

[Soap17]

Le pire nom de variable :

_

[barbouille]

Le pire nom de variable :

_

Ah oui ! Ca me rappelle un source que j'avais vu en contre exemple d'un chapitre sur la lisibilité du code.

Le programme s'appelle mystery.c, qu'avec des variables à 1 caractère (dont _), en une seule ligne (un appel récursif du main), et qui affiche ...

ben je vous laisse le découvrir ...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
#include <stdio.h>

main(t,_,a)
char *a;
{return!0<t?t<3?main(-79,-13,a+main(-87,1-_,main(-86, 0, a+1 )+a)):1,t<_?main(t+1, _, a ):3,main ( -94, -27+t, a)&&t == 2 ?_<13 ?main ( 2, _+1, "%s %d %d\n" ):9:16:t<0?t<-72?main(_,t,"@n'+,#'/*{}w+/w#cdnr/+,{}r/*de}+,/*{*+,/w{%+,/w#q#n+,/#{l,+,/n{n+,/+#n+,/#;#q#n+,/+k#;*+,/'r :'d*'3,}{w+K w'K:'+}e#';dq#'l q#'+d'K#!/+k#;q#'r}eKK#}w'r}eKK{nl]'/#;#q#n'){)#}w'){){nl]'/+#n';d}rw' i;# ){nl]!/n{n#'; r{#w'r nc{nl]'/#{l,+'K {rw' iK{;[{nl]'/w#q#\n'wk nw' iwk{KK{nl]!/w{%'l##w#' i; :{nl]'/*{q#'ld;r'}{nlwb!/*de}'c ;;{nl'-{}rw]'/+,}##'*}#nc,',#nw]'/+kd'+e}+;#'rdq#w! nr'/ ') }+}{rl#'{n' ')# }'+}##(!!/"):t<-50?_==*a ?putchar(a[31]):main(-65,_,a+1):main((*a == '/')+t,_,a+1 ):0<t?main ( 2, 2 , "%s"):*a=='/'||main(0,main(-61,*a, "!ek;dc i@bK'(q)-[w]*%n+r3#l,{}:\nuwloca-O;m .vpbks,fxntdCeghiry"),a+1);}

[ManusDei]

Ca me rappelle l'époque où je pensais que moins de lignes de code signifiait que le programme serait plus rapide

[Invité]

Ca me rappelle l'époque où je pensais que moins de lignes de code signifiait que le programme serait plus rapide

ça tient la route quand il s'agit d'un fichier javascript ou d'un fichier css à télécharger par le navigateur. Bah ! Moins il y a de caractères moins il y a d'octets et plus c'est rapidement téléchargeable. Pas pour rien qu'il y a les systèmes de "minification" qui te retire tous les espaces et te fout tout le code en une seule ligne.

[ManusDei]

Ah mais je parle de l'époque où j'apprenais le C

Et que je pensais que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

tab[++i]

était 2 fois plus rapide à l'exécution que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
i++;
tab[i];

J'ai produit plein de code super-rapide à l'époque

[downman72]

Dans le genre, on a un dev qui nous fait en php

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
       $resultat = $sql->GetListe();
       foreach($resultat as $resultat1){
          /* traitement des variables */
       }

Mais bon j'ai vu pire.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
       $quantite=0;
       $resultat = $sql->GetClasse();
       foreach($resultat as $resultat1){
          $quantite++;
       }

Diplôme d'ingénieur, sa fait peur.

[Bovino]

Je suis récemment tombé sur ce nom assez spectaculaire dans le code d'un collègue :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

lNbLignesTableauVide

[Bousk]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
$toto;
$toto2;
...
$toto_moins_toto2 = $toto2 - $toto; // dans l'autre sens le résultat est faux

[deathness]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
$toto;
$toto2;
...
$toto_moins_toto2 = $toto2 - $toto; // dans l'autre sens le résultat est faux

Elle est pas mal celle la ^^