Discussion :

[GrandFather]

Ca, ca me semble encore plus idiot comme affirmation. Ca a un sens en C (ou dans d'autres L3G non objet, plus vraiment utilisés - Pascal par exemple) ou le nombre de type utilisé est limité (et encore, pour les struct en C, les RECORD en pascal, il fait comment ?) mais ce serait absurde avec un langage objet.

J'aurais plutôt tendance à penser le contraire, préfixer les noms de variable par le type a moins d'intérêt dans des langages fortement et statiquement typés comme Pascal, où beaucoup de problèmes qu'est censé prévenir cette convention de nommage sont détectés dès la compilation.

Pour des langages objets dynamiquement typés, tel Ruby, ça peut se concevoir. Ruby est certes dynamiquement typé, mais il est aussi fortement typé: pas de transtypage automatique (seule exception, la substitution de variables dans les chaînes, et encore il s'agit de sucre syntaxique plutôt que d'un véritable transtypage).

On ne peut par exemple additionner une chaîne et un entier, il faudra que le développeur convertisse explicitement l'une des deux variables selon le type de l'autre pour décider du résultat de l'opération (une addition ou une concaténation), sous peine d'avoir une erreur à l'exécution. Dans ce contexte, ajouter "str_" devant un nom de variable devant contenir une chaîne peut aider à anticiper ce genre de problème.

[Bluedeep]

Pour des langages objets dynamiquement typés, tel Ruby, ça peut se concevoir. .

Effectivement, je n'avais pas envisagé la question des langages dynamiquement typés, ne mettant pas mon nez là dedans (avec la taille qu'il a, ça se saurait(*)) sauf à l'occasion javacript.









(*) Greg - Achille Talon pour les incultes

[Kaamui]

slt,

je pense que ca sert à rien. Ya deux types de classes, les classes à logique et les classes de stockage de données. Dans celles qui stockent les données, j'ose espérer que t'as pas une logique de fou. Donc t'as pas 36 cas différents de pointeurs et référence et ya juste à looker la déclaration dans le header.

Dans une classe avec logique, alors t'es pas censé avoir 50 membres, sinon faudrait ptet envisager de scinder la classe.

Bref dans la plupart des cas, tu auras qq membres, mais j'ai du mal à concevoir qu'il y en ai trop pour que le cerveau oublie les variables manipulées au sein de la méthode (faut-il rappeler que les méthodes sont censées être courtes)

C'est que tu n'a pas travaillé sur des applis de plusieurs millions de lignes de code, crois moi à ce moment là il est important de pouvoir rapidement savoir quel type (exact) de donnée tu manipule.

[zeyr2mejetrem]

En PHP, j'ai déjà vu des codes où le type était explicité par un préfixe.

Exemple:
bTemoin = booleen
sNom = string
asNoms = array de string

C'est très bien sauf quand tu dois changer le type d'une variable sur un programme déjà écrit ...
Dans ce cas tu es obligé de renommer toutes les occurrences

[Invité]

Pour ceux qui rigolent parce qu'ils voient des variables avec pour nom toto il faut savoir que la faute n'est pas totalement celle du développeur (parce que tout simplement tous les développeurs n'ont pas le même niveau de compréhension) mais aussi partiellement celle des professeurs (en tout cas pour mon prof de java) qui utilisent dans tous leurs exemples la variable toto, tata, titi au final ça devient ancré dans la tête des "mauvais" développeurs.

Tiens ça me rappelle l'histoire de l'élève qui demandait à son professeur de mathématiques ce que valait réellement x dans les équations à un seul inconnu parce qu'il apparaissait partout.

[DiDieuh]

Un petit truc très sympa aussi.
Je re situe un peu le contexte, une belle base de données, plein de tables, dont une (la principale), qui a comme nom de colonne :

-Var1
-Var2
-Var3
etc .....

Magnifique pour s'y retrouver =: )

[Bluedeep]

Pour ceux qui rigolent parce qu'ils voient des variables avec pour nom toto il faut savoir que la faute n'est pas totalement celle du développeur (parce que tout simplement tous les développeurs n'ont pas le même niveau de compréhension) mais aussi partiellement celle des professeurs

L'explication des professeurs ca va quand tu es sorti de l'école depuis 6 mois ou 1, au delà, faut être un peu gonflé pour s'abriter derrière cela.

[Freem]

C'est que tu n'a pas travaillé sur des applis de plusieurs millions de lignes de code, crois moi à ce moment là il est important de pouvoir rapidement savoir quel type (exact) de donnée tu manipule.

Je pense qu'alors, ton code est juste mal divisé.
Quelques millions de lignes de code, ou même des milliards ne changent rien au fait que chaque module de code ne devrait pas faire référence a beaucoup d'autres. Couplage fort => code moins réutilisable.

Le préfixe, pour moi, n'a pas pour vocation à permettre des vérifications à la compilation, j'ai plus l'impression qu'il sert dans les fonctions/modules à rallonge. Qui sont, en soi, déjà un problème.
A l'époque ou je trouvais l'idée intéressante, je l'avais découverte dans des tutos dont le code se résumait à une grosse fonction. Allez, je vais être gentil: 3 fonctions. 1 pour l'initialisation, 1 pour le programme lui-même, 1 pour le nettoyage. Du coup, les fonctions étaient assez illisibles, sans compter une pléthore de variables globales.
La, les préfixes permettaient de s'y retrouver. Ajouter à tout ce bordel des noms de variable génériques, et les préfixes deviennent absolument vitaux.

En fait, les préfixes servent quand (appliquer un ou inclusif):
_ les fonctions sont tellement loooonngues que les variables ont pour certaines une portées tout aussi étendue. Aggravé quand les déclarations se situent n'importe ou dans la fonction.
_ les variables possèdent des noms génériques.
_ il est impossible de créer des structures de données personnalisées.

Au sujet du 3ème point, le seul langage que je connaisse qui entre dans cette catégorie, c'est l'asm. Même le basic que j'ai appris (mon 1er langage... nostalgie) le permet: QB1.1. Donc, je pense que VB aussi le permet.
D'ailleurs, qbasic permettait de ne pas déclarer des variables, à condition de les préfixer par un caractère spécial selon le type.

En fait, j'ai constaté depuis que je fait de l'orienté objet (et plus du "C with classes"... il m'a fallu apprendre quelques temps tout de même) que pas mal de recommandations classiques d'écriture du code sont des aberrations pour les langages moderne, ainsi que pour le C (pour d'autres langages non OOP aussi je pense, puisque l'OO c'est un esprit, pas une fonctionnalité du langage. On peut coder en Java des trucs qui respectent rien de l'OO et en basic des choses très OO. Je peux même le prouver si nécessaire ) puisque ce sont des recommandations qui ne sont applicables que pour du code non réutilisable.

Genre, interdire les variables globales dans un module.
De nos jours, on appelle un module une classe. Et on y utilise des variables statiques, qui sont justement des variables globales pour cette classe (accessibles par chaque instance de celle-ci, c'est la même chose). Donc, variable globale au module.
Naturellement, il faut les éviter parce que ça peut pourrir du code, mais ça permet aussi des gains de performance élevé quand utilisé correctement.

Naturellement, les préfixes de type, pour lesquels j'ai déjà argumenté.

Les commentaires sont vitaux.
Pas dans un code dont les fonctions ne font qu'une chose, et sont bien nommées. Bon, allez, je l'accorde, il est toujours bon de commenter les paramètres passés en référence non constante, pour savoir s'il s'agit de sortie ou d'entrée/sortie. Et dans ce cas, par souci d'homogénéité, autant commenter le retour et les autres paramètres.
Documenter la fonction est aussi justifié, amha.
Mais de coller des commentaires sur des blocs de code qui sont en soit triviaux je pense que c'est juste que le bloc en question est en fait une fonction déguisée. Certaines lignes assez imbuvables, genre avec des opérations sur les bits, je dis pas, mais c'est plutôt rare. Les optimisations aussi, et les corrections de bugs empiriques méritent souvent aussi un commentaire. Mais ça reste tout de même pas si fréquent que ça. Et un commentaire est plus dur a maintenir qu'un nom de fonction. (erreurs de compilation quand la fonction change, donc on retrouve vite le tout et on peut corriger aussi vite)

Utiliser des fonctions pour le code dupliqué.
A bien y réfléchir, cette formulation fait penser aux débutants que seul le code dupliqué mérite d'être mis dans une fonction. L'argument le plus mis en avant dans ce que j'ai pu voir, c'est l'optimisation du code...
Alors que je pense que l'optimisation n'est pas l'objectif 1er des fonctions.

Et celle-ci, que je trouve juste... Magnifique en fin de compte: rassembler toutes les déclarations de variables en début de portée.
Génial, sauf les débutants oublient souvent qu'il n'y a pas que les fonctions qui limitent la portée. Les if aussi, et il est même possible (en C et C++ en tout cas) de créer des portées artificielles avec des { } sans if ou for ou autre. (je ne dis pas que c'est propre, hein, je dis juste que ça marche, et que même en mode parano, il n'y a pas de warning).
Donc les débutants se retrouvent avec des variables qui n'ont d'utilité que dans un seul if. Et comme ils en ont plusieurs, ils en utilisent qu'une pour tous ces ifs. Et donc, la variable sert a plusieurs trucs. Et au final, on change le nom pour un nom générique. Et voila, c'est le drame: pleins de variables aux noms génériques, tout ça pour grouper les déclarations.

Honnêtement, je pense que les recommandations devraient plutôt être:

1) Diviser au maximum le code en fonctions, qui ne devraient pas dépasser 50 lignes (et encore, je code en C ou en C++, qui ont la réputation d'être verbeux en terme de nombre de ligne de code - mais pas en longueur de ligne - ).

2) Utiliser des verbes d'action pour les fonctions. (Peu importe la langue, ça n'a d'influence que dans le cas du dev a plusieurs, et surtout dans le cas ou plusieurs nationalités bossent dessus.)

3) Eviter les valeurs en dur dans le code.
Les remplacer par des identifiants nommés rends clairement le code plus lisible. En plus, c'est plus simple d'ensuite modifier le code pour balancer ces valeurs dans des fichiers de conf.

4) Limiter au maximum la portée des variables.
Plus la portée est longue, plus le risque d'avoir tellement de variables déclarées qu'on ne sait plus qui fait quoi est important. Et plus on a de trucs en mémoire, au passage.

Bon, évidemment, je ne travaille pas avec des langages dynamiques, donc certains points peuvent changer, mais de manière générale, ces 4 recommandations me semble plus appropriées. Et bien sûr, en dehors des langages OO.
Pour un langage OO, j'ajouterai ceci:

5) Si une méthode d'une classe A n'utilise pas de données membres de A, et nécessite qu'on lui passe en paramètre les données d'une classe B, alors elle devrai être dans la classe B. (Certains codes en C++ abondent de ce genre de trucs)

6) Si une classe possèdent des données membres qui ne sont pas utilisées par au moins la moitié des méthodes, il est possible que la classe soit en fait 2 classes. Isoler les membres les moins utilisés avec les méthodes les utilisant dans une autre classe, qui héritera peut-être de la première.

C'est encore perfectible évidemment, et ce n'est sûrement pas absolu, mon expérience en tant que dev n'est pas encore immense. N'empêche, si j'avais lu ces recommandations plus tôt, j'aurai sûrement eu moins de problèmes avec mes programmes dans le passé.

Et c'est certainement très loin de ce que dit notre développeur sénior avec ses "je connaît la réponse à tout les maux de vos logiciels, codez comme moi".

[neljaouh]

Vu récemment :

- pourrire1
- pourrire2

[Bluedeep]

En PHP, j'ai déjà vu des codes où le type était explicité par un préfixe.

Exemple:
bTemoin = booleen
sNom = string
asNoms = array de string

Cela s'appelle de la notation hongroise, et si c'est relatviement adapté au C (et, pour mémoire, au Pascal - R.I.P. ), ce n'est pas sérieusement adaptable aux langages objet. (dans sa version dite "System", celle que tu décrits - dans la version "Apps", à la rigueur, mais faut pas en abuser - variables locales uniquement).

[souviron34]

-Var1
-Var2
-Var3
etc .....

Magnifique pour s'y retrouver =: )

Eventuellement, oui, c'est une excellente solution

Si on fait un moteur de base, on ne sait pas quels champs on manipule, juste le numéro de la colonne...

De la même manière lorsqu'on fait une calculette....

Cela s'appelle de la notation hongroise, et si c'est relatviement adapté au C (et, pour mémoire, au Pascal - R.I.P. ), ce n'est pas sérieusement adaptable aux langages objet. (dans sa version dite "System", celle que tu décrits - dans la version "Apps", à la rigueur, mais faut pas en abuser - variables locales uniquement).

Et non seulement il ne faut pas en abuser, mais c'est même recommandé de ne pas l'utilsier. Même en C...

Pour info, cette notation provient d'une erreur de traduction d'un auteur de Microsioft

La définition de la notation chez Microsoft :

Notation Hongroise

Et la définition de l'erreur :

MAking Wrong Code Look Wrong

In Simonyi’s version of Hungarian notation, every variable was prefixed with a lower case tag that indicated the kind of thing that the variable contained.
....
I’m using the word kind on purpose, there, because Simonyi mistakenly used the word type in his paper, and generations of programmers misunderstood what he meant.

En bref, cette notation non seulement complexiife les choses, mais n'est pas cohérente, et impose une refactorisation poussée pour peu que l'on modifie un élément (qu'on transforme une table en liste, un double en réel, un double en 64, etc etc)...

Elle est donc à fortement déconseiller dans la plupart des applis...


Maintenant, en ce qui concerne les noms/choses absurdes ou ne signifiant rien, ce n'est pas spécifique à la programmation... Un électronicien avec qui j'ai travaillé a fait une machine (médicale de surcroît) en mettant le bouton "marche" en rouge et "stop" en vert

Et il m'arrive souvent d'appeller mes varaibles i, j, k, , ... si je ne m'en sers que pour leur mettre une valeur temporaire, un indice de boucle, ou autre..

[zax-tfh]

$BritneySpears
$Tatayoyo

True story...

[Kaamui]

Je pense qu'alors, ton code est juste mal divisé.

Non ce n'est pas ça le problème. Le niveau de complexité est tel qu'à un certain moment tu ne peux plus faire autrement. Bon, il est clair que le code est pourri, mais pour d'autres raisons (C with classes pour expliquer rapidement). Il n'est pas mal divisé, et c'est un code qui évolue maintenant depuis plus de 10 ans, stable. Mais le fait que tu es besoin de connaitre le type rapidement tient du fait que ta productivité est importante, et si tu peux éviter toutes les recherches (systématiques) du type de données que tu manipule, tu gagnes un temps fou. Car quand tu arrive sur ce genre de projet, il te faut 5 à 6 ans pour faire le tour de 80% de l'appli et du code, alors imagine au début, le temps que tu passe à savoir quelle donnée tu manipule ?

Dans ma phrase, c'est de ça qu'il s'agit.

Sinon pour le reste de ton post, je suis d'accord, avec tout et je plussoie même pour la limitation de la portée des variables. Bon il est clair qu'entre le scope d'une fonction et d'un if unique qui suit, il n'y a pas de grande différence, mais à la longue et selon les cas (comme le traitement d'un objet lourd seulement après la condition passée), ça peut devenir contre-performant de ne pas y faire attention.

[AdmChiMay]

Il ne faut pas oublier que l'on code pour un client (même si le_client == mon_self), et aussi pour une équipe, qui passera probablement derrière. L'important, c'est que le nom des variables ait un sens dans le contexte client+programmeur.

Si j'ai affaire à une multiplication de matrices, je vais faire du

Code :

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

for i... for j... for k...

et pas du

Code :

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

for ligne_mat_A... for col_mat_B... for parcours_elements...

car les matheux à qui je m'adresse au final le notent i-j-k sur le papier. On trouvera la même approche pour une FFT, des équations différentielles, etc.

De même, si je code dans un environnement de chimistes, ou de modélisation/simulation d'ateliers flexibles (ou autre), il y aura forcément des noms, voir des acronymes, qui sont propres au contexte de travail du client.

Pour le côté "équipe", nous avons généralement des règles de "bonnes pratiques", qui se définissent au fil de l'expérience.

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

[Ottakar]

Des noms de village Alsaciens:
- niedermorshwhir
- pfastatt
- amerschwhir
- wittenheim
- ...

[Bluedeep]

Des noms de village Alsaciens:
- niedermorshwhir
- pfastatt
- amerschwhir
- wittenheim
- ...

Sont un peu courts comme exemples.
Niederschaeffolsheim par exemple, ça a plus de gueule.

[Hellwing]

Sont un peu courts comme exemples.
Niederschaeffolsheim par exemple, ça a plus de gueule.

Tiens, j'ai pensé exactement au même nom XD

[Pelote2012]

Un gars dans le framework professionnel développé par mon entreprise pour communiquer avec des machines outils avait mis en messages d'erreur : zoubidaPoilPoil. Le client a apprécié voir apparaître ça sur le moniteur.
Et moi aussi, j'était en test chez le client tout seul, en tznt que développeur de la partie métier, alors les message d'erreur du framework , jamais vu.
Je n'ai pas étét déçu

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