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 !!

[SurferIX]

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

T'as eu 14 down moi y compris, parce que le code d'exemple que tu montre est pour moi, non seulement clair du point de vue code, mais compréhensible : sans commentaire, j'arrive à comprendre ce qui se passe.

J'aimerais voir plus de code comme ça dans la vraie vie !

Je pense que tu as juste oublié de préciser le cadre : effectivement, si c'est dans des pages Web, alors ça aide beaucoup les gens mal-intentionnés, mais je ne ne vois pas d'autres problèmes.

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;

Parce que les gens ne savent :
- pas utiliser vim ("yy" ou "viw" puis "p" pour paste sans enlever les mains du clavier)
- pas faire un copier coller avec ctrl insert shift insert.

Ca fait le huitième cours de 4 heures que je fais avec mes étudiants, je leur explique, je leur rabâche que ctrl c ctrl v c'est dix fois plus long et moins pratique que déplacer avec les flèches et avec la même main, ctrl insert shift insert, ils me voient, ils hallucinent comme je suis rapide, mais tu crois qu'ils essaieraient ? Tu crois qu'ils se forceraient à changer ? Pas un seul, pas un seul sur plus de 20 étudiants n'a pris en compte mes commentaires. J'ai fait une petite session vim, à la fin ils ont tous voulu essayer, et ça a duré : 5 minutes. Oui oui, c'est bien une école qui forme des futurs informaticiens !

[gangsoleil]

Parce que les gens ne savent :
- pas utiliser vim

Pas un seul, pas un seul sur plus de 20 étudiants n'a pris en compte mes commentaires. J'ai fait une petite session vim, à la fin ils ont tous voulu essayer, et ça a duré : 5 minutes. Oui oui, c'est bien une école qui forme des futurs informaticiens !

[troll inside] Passe a emacs

Sinon, je suis globalement d'accord avec ce qui a ete dit : l'important est d'avoir des noms de variables explicites et suffisamment courts (ctrl p pour la completion des noms sous vim), avec toutefois quelques exceptions acceptables, comme i, j, k, ... pour les indices de boucle.

Ah si, ce qui est joli aussi, ce sont les variables explicitement nommees, mais reutilisees pour faire autre chose :

Code :

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

1
2
3
4
5
6
7
int age_capitaine;
...
printf ("Age du capitaine : %d", age_capitaine);
...
age_capitaine = 12; // On a des matrices de taille 12
...
tableau[age_capitaine] ...

[el_slapper]

J'ai vu quelques horreurs, mais au final, je laisse la parole à mon père, qui a 2 exemples particulièrement délicats(des années 80, le problème n'est pas nouveau) :

-des noms de variables en slovaque(alors que la boite est allemande)
-"pomme_de_terre", "kilo_de_pommes_de_terre", "carotte"; dans un programme comptable.

[Invité]

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.

[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 :

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;

[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é...

[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.

[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 ...

[Traroth2]

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.

J'en profite pour signaler un principe de nommage qui me parait fondamental pour obtenir des noms pertinents : ne pas nommer en fonction de l'utilisation qu'on fait de quelque chose, mais en fonction de ce que c'est.

Par exemple "calculTaxesFacture" n'est pas un bon nom de méthode, alors que "calculTVA", oui. Le jour où on voudra utiliser ce calcul pour autre chose qu'une facture, le résultat sera plutôt bizarre...

[atha2]

J'en profite pour signaler un principe de nommage qui me parait fondamental pour obtenir des noms pertinents : ne pas nommer en fonction de l'utilisation qu'on fait de quelque chose, mais en fonction de ce que c'est.

Par exemple "calculTaxesFacture" n'est pas un bon nom de méthode, alors que "calculTVA", oui. Le jour où on voudra utiliser ce calcul pour autre chose qu'une facture, le résultat sera plutôt bizarre...

J'ai pas compris le problème (le dernier paragraphe => problème de formulation ?)... Si la fonction s'appelle "calculTaxesFacture" alors on ne l'utilise pas pour autre chose (je ne dit pas que c'est un bon nom, ça dépend du contexte). Dans cette exemple précis, si elle calcul la TVA, et qu'on veut calculer la TVA, alors le résultat sera correct. Par contre je plains celui qui passera derrière

Sinon plus ou moins d'accord pour le principe, ça favorise la réutilisation des fonctions mais nommer la fonction en fonction de l'utilisation qu'on en fait permet de rendre le programme plus lisible.

[-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.

[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).

[tonnebrre]

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

[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".

[Kaamui]

Bonjour à tous,

Personnellement, au boulot j'ai vu des trucs sympas :

sur une application d'une banque française publique dont je n'ai pas le droit de citer le nom :

Code :

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

1
2
   Type laVariableADDA;

laVariable c'est déjà suspect mais ce le fut encore plus quand j'ai découvert dans un commentaire : "20020321 - DDA/FFT 2147 - modification etc" ... il s'agissait des initiales du codeur qui effectuait la maintenance sur cette application.

Un peu dans le même registre : un fenêtre pour avertir d'un plantage : le titre de la fenêtre était "Un homme à bord" et dans une autre qui suit "Attention chef, ça glisse !"

Très marrant mais bon les infos pas top pour débugger

PS :
je suis en train de me faire une petite convention de nommage pour mes variables, paramètre, types énumérés etc, qui reprend les base du CamelCase et qui en plus décrit le plus précisément possible de quel type de donné il s'agit (dans le cadre d'un projet). Je suis donc venu sur ce site pour voir si des discussions tournaient autour de ce sujet, et je suis tombé sur ce topic fort intéressant (et poêlant ). Mon problème c'est que je veux absolument savoir le type exact de la variable que je manipule juste dans le nom et ça donne grosomodo :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
/*Données membres :

variable 	                                                              : variable
variable constante                                                     : Cvariable
pointeur sur variable                                                   : p_variable
pointeur sur variable constante                                     : p_Cvariable
pointeur constant sur variable                                          : Cp_variable
pointeur constant sur variable constante                             : Cp_Cvariable	
référence sur pointeur sur variable	                                    : r_p_variable
référence sur pointeur sur variable constante                        : r_p_Cvariable
référence sur pointeur constant sur variable                         : r_Cp_variable
référence sur pointeur constant sur variable constante           : r_Cp_Cvariable 
référence constante sur pointeur sur variable                        : Cr_p_variable
référence constante sur pointeur sur variable constante         : Cr_p_Cvariable
référence constante sur pointeur constant sur variable           : Cr_Cp_variable
référence constante sur poniteur constant sur variable constante : Cr_Cp_Cvariable

variable locale ou temporaire :  concaténer un "l" avec les règles de la partie "Données membre"
paramètre de méthodes : concaténer un "P" avec les règles de la partie "Données membre"

exemples d'utilisation dans un contexte d'une méthode d'une classe :*/
void Character::UpdateLife( const type* Pp_ClifeToSubstract )
{
		type* lp_lifeToSubstract = new type();
		*lp_lifeToSubstract = *Pp_Cvariable;
		DoSeomething(lp_variable);
		p_Cvariable = *lp_variable;
}

Ne soyez pas trop dur avec moi ce n'est qu'une phase de recherche

je trouve en tout cas que cela devient vraiment moche dans les cas les plus extrêmes...qu'en pensez vous ?

[zeyr2mejetrem]

Bonjour à tous,

Personnellement, au boulot j'ai vu des trucs sympas :

sur une application d'une banque française publique dont je n'ai pas le droit de citer le nom :

Code :

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

1
2
   Type laVariableADDA;

laVariable c'est déjà suspect mais ce le fut encore plus quand j'ai découvert dans un commentaire : "20020321 - DDA/FFT 2147 - modification etc" ... il s'agissait des initiales du codeur qui effectuait la maintenance sur cette application.

Un peu dans le même registre : un fenêtre pour avertir d'un plantage : le titre de la fenêtre était "Un homme à bord" et dans une autre qui suit "Attention chef, ça glisse !"

Très marrant mais bon les infos pas top pour débugger

PS :
je suis en train de me faire une petite convention de nommage pour mes variables, paramètre, types énumérés etc, qui reprend les base du CamelCase et qui en plus décrit le plus précisément possible de quel type de donné il s'agit (dans le cadre d'un projet). Je suis donc venu sur ce site pour voir si des discussions tournaient autour de ce sujet, et je suis tombé sur ce topic fort intéressant (et poêlant ). Mon problème c'est que je veux absolument savoir le type exact de la variable que je manipule juste dans le nom et ça donne grosomodo :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
/*Données membres :

variable 	                                                              : variable
variable constante                                                     : Cvariable
pointeur sur variable                                                   : p_variable
pointeur sur variable constante                                     : p_Cvariable
pointeur constant sur variable                                          : Cp_variable
pointeur constant sur variable constante                             : Cp_Cvariable	
référence sur pointeur sur variable	                                    : r_p_variable
référence sur pointeur sur variable constante                        : r_p_Cvariable
référence sur pointeur constant sur variable                         : r_Cp_variable
référence sur pointeur constant sur variable constante           : r_Cp_Cvariable 
référence constante sur pointeur sur variable                        : Cr_p_variable
référence constante sur pointeur sur variable constante         : Cr_p_Cvariable
référence constante sur pointeur constant sur variable           : Cr_Cp_variable
référence constante sur poniteur constant sur variable constante : Cr_Cp_Cvariable

variable locale ou temporaire :  concaténer un "l" avec les règles de la partie "Données membre"
paramètre de méthodes : concaténer un "P" avec les règles de la partie "Données membre"

exemples d'utilisation dans un contexte d'une méthode d'une classe :*/
void Character::UpdateLife( const type* Pp_ClifeToSubstract )
{
		type* lp_lifeToSubstract = new type();
		*lp_lifeToSubstract = *Pp_Cvariable;
		DoSeomething(lp_variable);
		p_Cvariable = *lp_variable;
}

Ne soyez pas trop dur avec moi ce n'est qu'une phase de recherche

je trouve en tout cas que cela devient vraiment moche dans les cas les plus extrêmes...qu'en pensez vous ?

Faudrait qu'on m'explique la notion de variable constante

[Kaamui]

Faudrait qu'on m'explique la notion de variable constante

le mot variable est peut-être mal choisi (porte à confusion en tout cas) mais remplace le par donnée membre si tu veux. Ou imagine une variable devenant temporairement constante (on n'a plus le droit de la modifier) pendant un certain temps (le temps d'une fonction par exemple) où elle ne sert qu'en lecture mais qu'on ne veut pas passer par copie.