Discussion :

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

[aspkiddy]

Code :

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

1
2
$isql = "UPDATE chp_ii SET mettre='$i', mettrei='$ii', mettreii=$iii";
	$iresult = mysql_query($isql, $iiiii);

j'imagine que cela devrait être quelques choses comme cela :

Code :

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

1
2
3
$sql = "UPDATE nom_table SET nom_champs='$pommme', date='$now', nom_champs_quantite=$espece";
	$result = mysql_query($sql, $nom_database);

[saymoneu]

Si y'a bien un truc qui me rend fou au niveau du nommage des variables quand je retravaille le code de quelqu'un, c'est les variables avec un numéro derrière, utilisées 20 fois et pas claires du tout du genre somme1, somme2,... somme16, total1, moy13.

C'est vraiment dur à suivre des fois...

[goudax]

Perso, dans mon quotidien, je ne trouve pas trop d'horreur en terme de variable, mais j'essaie de prendre l'habitude (ce qui n'est pas toujours facile qd on doit aller vite) de préfixer du type (intCompteur, ou strQuery, ...) Par contre, je suis obligé (et affligé) (en tout cas pour le moment) de jouer avec des horreurs en matière de nom de table et de champs SQL.
Ex: tbl_customerorderpreparationusertime (pour le nom de la table) avec orderpreparationusertime_customerorder comme nom de champ ( et on a de la chance, le préfixe du champ été raccourci) Imaginez les requêtes (et vive les alias)

Je crois qu'il faut un juste milieu entre var1, var2, ... var298547 et
int64MontantTotalDuDocumentAFacturer (par exemple)

[Louis-Guillaume Morand]

Perso, dans mon quotidien, je ne trouve pas trop d'horreur en terme de variable, mais j'essaie de prendre l'habitude (ce qui n'est pas toujours facile qd on doit aller vite) de préfixer du type (intCompteur, ou strQuery, ...) Par contre, je suis obligé (et affligé) (en tout cas pour le moment) de jouer avec des horreurs en matière de nom de table et de champs SQL.
Ex: tbl_customerorderpreparationusertime (pour le nom de la table) avec orderpreparationusertime_customerorder comme nom de champ ( et on a de la chance, le préfixe du champ été raccourci) Imaginez les requêtes (et vive les alias)

alors là je suis d'accord et pas d'accord. D'un côté en SQL, je préfixe effectivement mes tables par T_, mes vues par V_, autant en code pur (C# notamment), la variable s'appelle juste par ce qu'elle contient (montantTVA).
Par contre, j'avoue que j'ai aussi des toto quand ca me saoule

ps: la notation intMontant, strNom est à proscrire maintenant car c'est la vieille notation hongroise (on mettait szNom pour une chaine) car maintenant, tu passes ton curseur sur la variable et tu connais le type. Disons que dans une methode de calcul mathematique, t'auras quasi que des int/double donc pourquoi le préciser, idem dans une methode de gestion de chaine de caractère, meme complexe.

[tiracoon]

vous connaissez la variable ok?
J'ai un collègue qui passe son temps à mettre des "if (ok)" pour suivre un statut sans comprendre qu'en réorganisant ses boucles ou en utilisant le "not" il pouvait l'éviter.... ou tout au moins la nommer en indiquant ce qui est ok... Dans des procédures de parfois quelques centaines de lignes je ne vous parle pas du casse tête pour suivre sa variable....

[Anything]

1. Une série de x, xx, X, XX, dx, dX dans la même méthode(avec leur homologues en Y c'est pas drole sinon). J'ai passer je ne sais combien de temps à essayer de comprendre ce que fesait les boucles imbriquées.


2. Des noError et des notOk, mais c'est surtout l'utilisation qui en était faite qui m'agacait:

if (!noError)
{
...
}

Les doubles négations c'est le mal!

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

[ericduval]

J'ai souvent rencontré des variables du genre :

int compteur = 0;
int Compteur = 0;

ou :

int foo = 0;
int bar = 0;
int foobar = 0;

[goudax]

alors là je suis d'accord et pas d'accord. D'un côté en SQL, je préfixe effectivement mes tables par T_, mes vues par V_, autant en code pur (C# notamment), la variable s'appelle juste par ce qu'elle contient (montantTVA).
Par contre, j'avoue que j'ai aussi des toto quand ca me saoule

Je suis d'accord sur le préfixe T_ ou V_, et je préfixe/suffixe même mes SP en fonction de leur usage(USP_, EXP_,_UPD, _INS, ...) mais l'exemple portait surtout sur le nom de la table lui-même que je trouve à rallonge.

[Hellwing]

ps: la notation intMontant, strNom est à proscrire maintenant car c'est la vieille notation hongroise (on mettait szNom pour une chaine) car maintenant, tu passes ton curseur sur la variable et tu connais le type. Disons que dans une methode de calcul mathematique, t'auras quasi que des int/double donc pourquoi le préciser, idem dans une methode de gestion de chaine de caractère, meme complexe.

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.

[souviron34]

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.

voir plus haut les citations des désavantages de ces notations..

[el_slapper]

voir plus haut les citations des désavantages de ces notations..

Ca peut être utile, si le préfixe a un sens beaucoup plus fonctionnel. Je n'ai pas retrouvé l'article ou Joel Spolsky expliquait que dans Excel, il y avait un préfixe obligatoire pour toute variable "ligne" et un autre pour toute variable "colonne"(et j'imagine qu'il y en a un paquet). J'ai connu une banque qui imposait des préfixes pour "Label, Code, Nombre, Montant, Numéro, Identifiant"(et y'en avait deux autres que j'ai oublié).

Dans les deux cas, ça permet de visualiser les aberrations : alimenter un Montant avec un code, ou une ligne avec une colonne, ça saute aux yeux, et ça ne peut pas être bon.

Mais clairement, le format en préfixe, bof. D'autant que, suivant le langage, on peut parfaitement mettre un alpha dans un numérique, ou l'inverse - aussi longtemps que le signifié reste le même(un code produit reste un code produit, qu'il soit alphanumérique ou numérique).

[souviron34]

il y avait un préfixe obligatoire pour toute variable "ligne" et un autre pour toute variable "colonne"(et j'imagine qu'il y en a un paquet). J'ai connu une banque qui imposait des préfixes pour "Label, Code, Nombre, Montant, Numéro, Identifiant"(et y'en avait deux autres que j'ai oublié).

Oui, mais ce sont des préfixes fonctionnels

Pas sur le type (informatique) de la variable..

[Bluedeep]

Ca peut être utile, si le préfixe a un sens beaucoup plus fonctionnel.

C'est précisément la raison pour laquelle les critiques sur la notation hongroise portent essentiellement sur la version dite "System" alors que ce que tu décrits est la version dite "Apps" de ladite notation.

[deuz59]

Une bonne référence en la matière : "Coder proprement" de Robert C. Martin

Une variable doit avoir une "responsabilité unique" et son nom doit la retranscrire précisément. Ne pas hésiter à la renommer quand on repasse sur le code si elle reste trop flou.
Perso je préfère un nom à rallonge qui indique peut être que le code doit être repensé qu'un nom générique qui indique qu'on ne saura jamais ce qu'il fait !

[Hellwing]

voir plus haut les citations des désavantages de ces notations..

On s'est mal compris. Il s'agit d'une variable locale, intermédiaire, dont le préfixe consiste juste à avoir un nom de variable différent. Le rôle principal de ce préfixe n'étant pas de définir de quel type on parle. J'aurai très bien pu utiliser "totoMonParametre" mais c'est moins lisible.

[Thorna]

Vaste débat, si j'en crois le nombre de pages par jour... Et qui, comme la plupart des vastes débats du domaine informatique (et de tout autre domaine d'ailleurs) fait ressortir un certain nombre de règles ou de pratiques conseillées et pas toujours respectées, et aussi beaucoup de "clochers" qui défendent leur religion becs-et-ongles.
Ce qui me parait souhaitable, c'est que le code soit lisible. Pas uniquement par celui qui l'écrit, mais aussi par ceux qui corrigeront ensuite. Pas du tout par le client, à moins qu'il entre dans une des 2 catégories. Et "lisible", ça ne veut pas dire la même chose pour tout le monde :

• avec des noms de variable (peut-être longs) significatifs ? Du genre "maCommande", "nombreClients", etc.
• avec des noms de variables "classiques" ? Du genre i, j, k dans les boucles.
• avec des noms de variables "surchargés" par tout un tas de préfixes de types, de genre etc.
• avec des noms de variables dans la langue des lecteurs.
• etc.

"Coder systématiquement en anglais parce que c'est comme ça" n'est pas forcément une bonne pratique. [...] 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.

+1

J'ai travaillé avec un collègue qui accentuait les nom de variable. Que du bonheur!!!

Et... ? L'UTF8, c'est pas que pour faire de l'ASCII-7bits !

[GrandFather]

Et... ? L'UTF8, c'est pas que pour faire de l'ASCII-7bits !

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

[deuz59]

Sous un autre point de vue, des noms de variables pourris, confusant, c'est bon pour la sécurité => plus besoin d'obfusquer le code s'il est déjà illisible par ses propres développeurs