Discussion :

[ProgVal]

Une fois, on m'a demandé de déboguer un code, avec une classe dont tous les accesseurs étaient nommés toString(), toString1(), toString2(), ..., toString23().


Dans le sujet de mon dernier DM d'info, les noms de fonctions et de variable traitant de listes semblaient utiliser au hasard "lst", "list", "liste", "lists", et "listes".

[Pill_S]

Je ne suis pas de l'avis de M. Lester.... Les noms de variables volontairement "obfusqués" peuvent être utiles. Pour ma part, j'opère un distingo en fonction de la portée d'une variable.

Tout ce qui est local, est volontairement "mal nommé", quelques lettres tout au plus, et des chiffres pourquoi pas. Cela car la durée de vie de ces variables étant très limitée, leur donner un nom bien choisi relève de l'overkill, et tend à indiquer qu'elle a une certaine importance ou dissipation dans le programme, alors que ce n'est pas le cas.

Tout ce qui peut "déborder" hors du block/méthode courant (surtout les champs finalement...) possède un nom nettement mieux réfléchi (mais sans préfixe de type ou autre notation hongroise, car je fais du java et que les outils sont suffisament puissants pour qu'on n'ait pas besoin de tels artifices).

Du coup c'est clair, les petits noms font partie de l'implémentation du bout de code local, le reste a une durée de vie bien plus longue... Un petit commentaire si vraiment l'implém est compliquée, et encore, et aucune fonction ne dépassant 100 lignes et c'est dans la boite, coco!

[air-dex]

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 :

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

1
2
int a;//age du capitaine

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

Code :

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

1
2
int age_du_capitaine;

Pour les noms de variables assez courts, est-ce que cela ne remonte pas à une époque où les développeurs n'avaient pas d'autocomplétion et où ces derniers avaient autre chose à faire que de finir d'écrire des noms de variables à rallonge ? Tout le monde n'a pas toujours eu un Ctrl+Espace pour finir de taper un nom d'une variable.

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

Pas forcément d'accord. "Coder systématiquement en anglais parce que c'est comme ça" n'est pas forcément une bonne pratique. À mon avis le choix de la "langue de développement" dépend aussi de celles des développeurs derrière leur code. Est-ce un crime que de coder en français un programme dont on sait pertinemment qu'il ne sera jamais regardé par des personnes non francophones (comme un programme fait par et pour soi-même par exemple) ? Je ne le pense pas, bien au contraire.

Pour moi la langue d'un programme devrait être avant tout la langue (maternelle) des développeurs qui ont affaire au code. Et ils ne sont pas toujours tous forcément anglais.

[Peacecraft95]

Histoire de rendre plus gaie mon job, j'ai appelé une méthode "PutChildInDaHouse" (cela concerne les assurances habitations).

Sinon, je suis classique avec les var cpt, compteur ... etc etc.

[auxiliaire]

ben justement le probleme est que cette équipe peut partir et laisser le projet à d'autres développeurs. On sait jamais!

[nu_tango]

Concrètement, dès que l'on commence à avoir moultes variables (fonctions mathématiques, physiques, etc.) on se retrouve avec des choses telles que (par exemple) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 int mandel(double px, double py) {
    double zx = 0.0, zy = 0.0;
    double zx2 = 0.0, zy2 = 0.0;
    int value = 0;
    while (value < MAX && zx2 + zy2 < 4.0) {
      zy = 2.0 * zx * zy + py;
      zx = zx2 - zy2 + px;
      zx2 = zx * zx;
      zy2 = zy * zy;
      value++;
    }
    return value;
  }

Qui n'est vous en conviendrez, succint mais pas des plus lisible.
Pour ce qui est de la lisibilité, des "vrais exemples de best practices" sont introduit dans l'ouvrage de Robert C. Martin cité précédement par elmcherqui : Clean Coding (Coder Proprement) que je recommande vivement à tout développeur (les exemples sont malheureusement seulement en java...) un tant soit peu consciencieux.

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.

Oui mais il ya du pour et du contre dans le leur utilisation tel que. D'aucuns disent qu'une syntaxe telle que celle ci-dessous :

Code :

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

1
2
3
4
5
	for (int fruitNumber = 0; fruitNumber < fruits.size(); fruitNumber++) {
			if (fruits.get(fruitNumber).isBanana()) {
				// What to do with bananas
			}
		}

bien que plus verbeuse est à préférer à quelquechose de ce style :

Code :

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

1
2
3
4
5
6
for (int i=0;i < f.size(); i++) {
			if (f.get(i).isB()) {
				// What to do with bananas
			}
		}

[ProgVal]

Pour les noms de variables assez courts, est-ce que cela ne remonte pas à une époque où les développeurs n'avaient pas d'autocomplétion et où ces derniers avaient autre chose à faire que de finir d'écrire des noms de variables à rallonge ? Tout le monde n'a pas toujours eu un Ctrl+Espace pour finir de taper un nom d'une variable.

Je n'ai pas d'autocomplétion (Python + Vim), et ça ne m'empêche pas d'utiliser parfois des noms qui font plus de dix, voire quinze caractères.

[Freem]

Je n'ai pas d'autocomplétion (Python + Vim), et ça ne m'empêche pas d'utiliser parfois des noms qui font plus de dix, voire quinze caractères.

Hum... CTRL+N sur vim pour auto-compléter un nom de symbol local. Sinon je crois qu'il y a un autre artifice, avec les ctags. Bon , je peux me planter, je suis pas expert vim, mais ça marche en c++.

Concrètement, dès que l'on commence à avoir moultes variables (fonctions mathématiques, physiques, etc.) on se retrouve avec des choses telles que (par exemple) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 int mandel(double px, double py) {
    double zx = 0.0, zy = 0.0;
    double zx2 = 0.0, zy2 = 0.0;
    int value = 0;
    while (value < MAX && zx2 + zy2 < 4.0) {
      zy = 2.0 * zx * zy + py;
      zx = zx2 - zy2 + px;
      zx2 = zx * zx;
      zy2 = zy * zy;
      value++;
    }
    return value;
  }

Qui n'est vous en conviendrez, succint mais pas des plus lisible.
Pour ce qui est de la lisibilité, des "vrais exemples de best practices" sont introduit dans l'ouvrage de Robert C. Martin cité précédement par elmcherqui : Clean Coding (Coder Proprement) que je recommande vivement à tout développeur (les exemples sont malheureusement seulement en java...) un tant soit peu consciencieux.



Oui mais il ya du pour et du contre dans le leur utilisation tel que. D'aucuns disent qu'une syntaxe telle que celle ci-dessous :

Code :

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

1
2
3
4
5
	for (int fruitNumber = 0; fruitNumber < fruits.size(); fruitNumber++) {
			if (fruits.get(fruitNumber).isBanana()) {
				// What to do with bananas
			}
		}

bien que plus verbeuse est à préférer à quelquechose de ce style :

Code :

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

1
2
3
4
5
6
for (int i=0;i < f.size(); i++) {
			if (f.get(i).isB()) {
				// What to do with bananas
			}
		}

Dans ton cas, il aurait suffit que "f" ait été nommé "fruits" pour que le code soit lisible. Et même plus que le 1er.
D'ailleurs, je ne sais pas de quel langage tu parles, mais pour java il y a des for_each, et pour c++, des algo qui font la même chose (le for_each d'avant C++11 est immonde imho, et je ne considère donc que le C++03 ici).

D'ailleurs, en C++ ça aurait plus donné ceci dans ma convention perso:

Code :

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

1
2
3
4
5
6
7
8
9
typedef FruitIter vector<Fruit>::iterator ;
for (FruitIter it=fruit.begin();it < fruit.end(); ++it)
{
  if(it->isBanana())
  {
      // What to do with bananas
  }
}

Bon, sans find_if, évidemment. Mais la on a juste la variable de boucle qui n'a pas de vrai nom, et pourtant, je pense que ça reste très lisible. Peut-être même plus que ton 1er exemple (j'imagine que ça peut dépendre des gens)

Et en 2011 (qui ne fait que rattraper d'autres langages), ça aurait fait ceci:

Code :

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

1
2
3
4
5
6
7
8
for(auto &i: fruit)
{
  if(i.isBanana())
  {
    //...
  }
}

La, je trouve que ça ne souffre plus la comparaison. D'autant que le i est communément utilisé.

[LooserBoy]

Pas forcément d'accord. "Coder systématiquement en anglais parce que c'est comme ça" n'est pas forcément une bonne pratique. À mon avis le choix de la "langue de développement" dépend aussi de celles des développeurs derrière leur code. Est-ce un crime que de coder en français un programme dont on sait pertinemment qu'il ne sera jamais regardé par des personnes non francophones (comme un programme fait par et pour soi-même par exemple) ? Je ne le pense pas, bien au contraire.

Pour moi la langue d'un programme devrait être avant tout la langue (maternelle) des développeurs qui ont affaire au code. Et ils ne sont pas toujours tous forcément anglais.

Je dois être bizarre car même à titre personnel, dans un passé pas si lointain (j'ai arrêté, ma psychothérapie a fonctionné ), je codais en anglais. C'est probablement par la force des habitudes ou le fait que l'anglais soit ma deuxième langue, après le français, apprise très jeune et qui, par conséquent, ne me pose strictement aucun problème.

[djinneo]

fonctions mathématiques

j'ai lu hier:
si "z" est le rayon d'une pizza et "a" son épaisseur, alors son volume est donné par: Pi*z*z*a

[ProgVal]

Hum... CTRL+N sur vim pour auto-compléter un nom de symbol local. Sinon je crois qu'il y a un autre artifice, avec les ctags. Bon , je peux me planter, je suis pas expert vim, mais ça marche en c++.

Excellent, merci

Même si ça ne peut pas être parfait pour un langage dynamique, ça reste très utile dans 95% des cas.

[atha2]

Et en 2011 (qui ne fait que rattraper d'autres langages), ça aurait fait ceci:

Code :

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

1
2
3
4
5
6
7
8
for(auto &i: fruit)
{
  if(i.isBanana())
  {
    //...
  }
}

La, je trouve que ça ne souffre plus la comparaison. D'autant que le i est communément utilisé.

i est communément utilisé en tant que variable représentants un indice. Ici i est un éléments de la liste fruit, j'aurai donc plutôt tendance à l'appeler e (pour élément) ou f ou même fruit (en renommant fruit par fruitS).

[guidav]

Classique mais efficace, les variables de debug $foo, $bar, $foobar, $barbar qui restent pour une appli en prod.
Evidemment, le combo avec $foo1 est accepté.
La variable $tableau est courante aussi.

[Uther]

Comme toujours tout dépends du contexte. Par exemple dans une méthode write(char[] data, int offset, int length) je ne vois pas en quoi l'usage de data ne serait pas adapté.

De même, je ne voit pas vraiment de souci non plus à nommer des index qui ne servent qu'à faire une simple itération : "i", "j", "k". Quant à utiliser x et y pour une abscisse est une ordonnée, c'est juste du bon sens tant qu'on en manipule qu'une paire...

J'ai rarement de problème avec les nom de variables dans les langages comme le C++/Java/... qui font que les variables ont le plus souvent des portées plutôt réduites.
J'ai l'impression que c'est un problème plus caractéristique de langagues comme le VB ou le JavaScript qui même s'il ont des systèmes pour réduire la portée me donnent l'impression d'encourager a avoir des variables avec de longues portées.

[la.lune]

En tout pour des programme de calcul intense surtout en programmation parallèle ou vectoriel la longueur de la variable n'est pas quelque chose à négliger, ça se voit considérablement dans le temps de l’exécution, ce qui fait que dans ces cas vaut mieux des variable plus courtes comme des variables mathématiques .

D'où que je rejoint l'idée selon laquelle ça dépend du contexte.

[Jaepetto]

un de mes collègues avait pris l'habitude d'appeler ses variables t, tt, ttt, tttt, ttttt... c'était la grosse déprime quand il fallait passer derrière lui...

[bugsan]

i est communément utilisé en tant que variable représentants un indice. Ici i est un éléments de la liste fruit, j'aurai donc plutôt tendance à l'appeler e (pour élément) ou f ou même fruit (en renommant fruit par fruitS).

+1 !

j'écris toujours "for (Fruit fruit : fruits) { ... }"

[jnspunk]

Au taf, je rigole parfois en voyant des :

Code :

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

toto = ;

Sinon à l'inverse ceux qui sont un peu trop dans leur trip :

Code :

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

boolean est_la_valeur_entre_10_et_20 = ;

[kolodz]

....
N’importe quelle variable qui s’appuie sur un chiffre pour se distinguer d’une autre doit être immédiatement renommée.
....

Quand tu manipule l'enfant 3 et que tu veux que ça soit l'enfant 3 et pas 2 ni 4 du couple... Tu le distingue avec un chiffre.

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

Oui, de manière exceptionnelle.

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

Non de variable dans une classe :
a b x y p
(5 variables classes sans commentaire)

[kolodz]

Quand tu manipule l'enfant 3 et que tu veux que ça soit l'enfant 3 et pas 2 ni 4 du couple... Tu le distingue avec un chiffre.


Oui, de manière exceptionnelle.

Nom de variable dans une classe :
a b x y p
(5 variables classes sans commentaire)