Comment nommez-vous vos variables ?

Bonsoir !

J’ai une petite question à vous poser. Je vais vous présenter deux codes, et j’aimerais que vous m’indiquiez lequel pour préféré (ou lequel utilisez vous le plus) et pourquoi.

Code 1 :

1
2
3
4

<?php
$imageSource = null;
$imageDestination = null;
$numberUser = 5;

Code 2 :

1
2
3
4

<?php
$imageSrc = null;
$imageDest = null;
$nbUser = 5;

Alors ? Comment nommez-vous vos variables ?

Merci !

En général j’abrège un peu, dans le style du deuxième code. Les noms du premier code sont plus lisibles mais des noms longs ça a des inconvénients :

• quand ça fait 80 fois que tu tapes Destination, avec une typo une fois sur dix, t’en as marre
• si t’as des lignes de code un peu complexes qui font intervenir quatre ou cinq variables, si elles ont toutes des noms de 20 caractères ça devient un peu lourd

Mais je ne suis pas fan de l’extrême inverse, style Linux. Les mkdir, chmod, strcat, dup, etc. La philosophie là dedans c’est que t’as une courbe d’apprentissage un peu plus raide mais une fois que tu connais la plupart des éléments ça permet d’aller beaucoup plus vite. Dans Linux c’est cool parce que c’est ultra répandu, ultra utilisé et tout le monde connaît. Mais dans un autre contexte, je ne validerais pas un code plein de bestioles dans ce genre. C’est illisible et incompréhensible si ce n’est pas bien documenté. Et c’est toujours mieux un code qui parle de lui-même.

Ça dépend, par ordre pseudo-décroissant d’importance :

• du style déjà mis en place si c’est un code préexistant ;
• de qui lira/modifiera le code à l’avenir ;
• de la durée de vie du code ;
• de la portée de la variable.

L’idée générale étant que plus une variable est susceptible d’être lue par d’autres humains, plus le nom sera détaillé. Si c’est une pauvre variable aidant l’écriture d’un corps de fonction d’un script à l’arrache dont je serais le seul lecteur, je vais pas m’embêter. Si c’est une variable d’entrée d’un programme utilisé par plusieurs personnes, je vais la nommer de la façon la plus claire possible.

Mais je ne suis pas fan de l’extrême inverse, style Linux. Les mkdir, chmod, strcat, dup, etc. La philosophie là dedans c’est que t’as une courbe d’apprentissage un peu plus raide mais une fois que tu connais la plupart des éléments ça permet d’aller beaucoup plus vite.

Ne pas oublier que ces noms là ont été choisis à l’époque à cause de contraintes historiques (pour UNIX puis par POSIX). L’éditeur de lien à l’époque ne savait géré des noms que de 8 caractères maximum.

Sans oublier le K&R qui en C a répandu la pratique des noms courts, là encore à cause des contraintes d’impression. L’ensemble a formé une culture.

Ni la première, ni la deuxième.

J’abuse des underscores pour ma part :

$im_source, $im_dest, $n_users, $cookie, $hash_psw, $login...

Pour ma part j’utilise plutôt des noms courts, a, n, t, zz, etc.

Ne pas écouter dab, c’est un troll de l’espace. Perso j’écris toujours en entier les mots pour plus de lisibilité.

J’ai une histoire sur ce sujet.

En PHP/Symfony il est assez commun d’aliaser certains trucs comme $entityManager en $em ou dans une requête User u. Cela va clairement à l’encontre des bonnes pratiques qui visent à écrire un code simple et limpide. Bonnes pratiques qu’on enseigne naturellement à tous les développeurs de nos équipes. Un jour un stagiaire me demande "Pourquoi em ? Et c’est quoi ces trucs dans les requêtes SQL?", je lui explique, il me dit "wtf, mais vous m’avez dit qu’il fallait écrire du code clair et vous écrivez en hiéroglyphes".

Il avait raison, ce stagiaire.

Du coup, 100% sur ta première solution, et même un peu plus :

1
2
3
4
5

<?php

$imageSource = null;
$imageDestination = null;
$numberUserMaxAvailableForAComment = 5;

Après il faut faire un peu gaffe, avec des variables aussi longues que la dernière que tu as écrites, tu finis par écrire du Java sans t’en rendre compte.

Salut,

Personnellement je préfère utiliser des noms de variables très explicites, quitte à ce que ça prenne un peu plus de caractères. L’essentiel est que le code soit lisible, compréhensible et facilement maintenable. Par contre je ne me prive pas d’utiliser des abréviations usuelles comme $imgSrc $imgDest $nbUser lorsque l’on sait tout de suite de quoi il s’agit.

Salut,

Mais je ne suis pas fan de l’extrême inverse, style Linux. Les mkdir, chmod, strcat, dup, etc. La philosophie là dedans c’est que t’as une courbe d’apprentissage un peu plus raide mais une fois que tu connais la plupart des éléments ça permet d’aller beaucoup plus vite.

Ne pas oublier que ces noms là ont été choisis à l’époque à cause de contraintes historiques (pour UNIX puis par POSIX).

Yep, il y a une anecdote amusante là-dessus d’ailleurs.

Sinon, les noms que je donne dépendent le plus souvent de la portée de la variable. Plus elle est courte (typiquement un compteur de boucle) plus il sera court et inversement. Toutefois, j’ai tendance à abréger dans tous les cas, je n’écrirais pas number_of_instances par exemple mais plutôt ninst ou ninstances. Donc code 2 pour ma part.

Salut

Je fais aussi partie de cette "école de la variable" qui consiste à écrire sans abréviation. Cependant, je déteste les underscore dans mes variables, je préfère les garder pour mes id/class en HTML. C’est juste MES conventions, et comme ça je me repère facilement.

Il y a cependant quelques mots clés qui reviennent souvent comme "Nombre, image, mot de passe…" que j’abrège en "nbr, img, mdp…".

J’ai aussi une technique secrète (ou pas), j’utilise un maximum l’anglais. Quand on voit que des mots comme Utilisateur qui s’écrivent en 4 lettre en anglais (user), autant en profiter !

Oui et non. $em étant une convention de Symfony, normalement n’importe quel développeur qui fait du Symfony depuis plus de 3 jours doit la comprendre. Là où ça devient ennuyeux, c’est qu’avant on récupérait effectivement l’objet avec un getEntityManager() qui est désormais déprécié ; il faut utiliser getManager(), qui de mémoire n’est plus un EntityManager mais un ObjectManager. La variable $em n’est donc plus un raccourci correct. Ceci étant dit, cela reste vrai avec $entityManager qui en réalité est un ObjectManager.

Sinon pour ma part, tout en anglais, en (lower) camelCase, sans abréviation.

Merci à tous pour vos réponses.

Ca fait pas mal de personnes qui donnent des noms assez différent à leurs variables.

Personnellement, je suis comme @skywhi, je nomme mes variables en utilisant le nom complet sauf lorsque il s’agit de choses "connu" comme "source", "number", ou "destination".

Et ça m’a d’ailleurs coûté deux points en moins dans mon devoir…

Du coup, je risque d’écrire des nom à rallonge maintenant.

Concernant les underscore ou le lower camelCase, je préfère de très loins la seconde option. Je trouve cela bien plus joli que les underscore (et puis sinon je me fait taper sur les doigts lors de mes devoir…).

Juste pour le choix camelCase ou non, perso je suis ce que me dit le linter du projet generalement ou ce qui est generalement utilises dans les projets avec ce langages (Rust donne des conventions par exemple)

Pour ma parr, j’ouvre Google Maps sur la Pologne et j’utilise des noms de villes polonaises.

Corollaire à ce que dit @Taurre : plus ton code sera bien découpé, plus tes variables pourront se permettre d’avoir un nom court sans pour autant perdre en précision. Donc, utiliser les outils mis à disposition par le langage pour bien organiser son code aide.

Par exemple, si j’ai un endroit où je modifie une image (par exemple en l’assombrissant), je fais une fonction qui fait ça, et dans cette fonction utiliser comme nom de variable src et dst ne paraît pas gênant vu qu’on a bien nommé la fonction.

Comme ça en plus d’être imprononçable c’est aussi intapable sans faire de typo et illisible en bonus Après c’est une méthode d’obfuscation comme une autre hein (par contre faut un langage qui supporte les caractères alakon).

C’est pour pas se faire voler son code, comme ça ses variables sont incompréhensibles

Bonjour,

La question et la diversité des réponses est amusante.

Au boulot, je mets des noms souvent assez longs parce qu’il doivent être suffisament clairs pour toute l’équipe et parce qu’il y a des conventions pour ça.

Maintneant pour mes codes perso qui ont une probabilité quasi-nulle d’être lus par quelqu’un d’autre que moi, y compris ceux qui sont sur mon github:

• Pour les variables d’instance ou les variables globales: je choisis de préférence des noms courts, mais hormis pour les mots vraiment trop casse-pied a écrire, je prends quand même des mots entiers;
• Pour les variables de boucle ou de fonctions/méthodes relativement courtes, j’utilise assez souvent des noms qui ont 4 caractères ou moins
• J’ai horreur du franglais; donc je choisis des noms en anglais de préférence
• Ayant été bercé au Java, j’ai adopté camelCase, et je réserve SNAKE_CASE pour les constantes; ailleurs dans le code je déteste snake_case.
• Je réserve le pluriel pour les listes, tableaux et autres collections; les scalaires et objets simples sont au singulier

Je ne suis vraiment pas fan de la convention que certains soutiennent à vouloir systématiquement préfixer les noms par des indications de portée ou de type: m/g pour membre/global, n/nb/i/l pour int/long, s/str pour string, f pour float/double, etc. Je trouve que ça n’apporte strictement rien et je pars du principe que le nom de la variable devrait être assez clair pour qu’on n’ait pas besoin de rappeler son type ou sa portée. Ceux qui font du C++ sont les spécialistes pour faire ça, mais je l’ai déjà vu en PHP aussi.

Du coup pour répondre par rapport à l’exemple, si ce sont des variables d’instance ou globales, alors pour moi ce sera sûrement respectivement $source, $destination pour les deux premières, et $userId, $user ou $nbUsers selon ce qu’elle va stocker exactement (avec juste l’exemple ce n’est pas assez clair si on y stocke un ID, un objet ou un nombre d’utilisateurs) pour la troisième. Ce nom ne changerait pas beaucoup quelque soit le langage (je fais toujours du camelCase y compris en C++ et en python).

En tout cas j’aurais probablement omis le mot image du nom car ça m’aurais probablement paru comme étant une évidence dans le contexte, qu’on est en train de travailler avec des images.

Voilà pour moi !

Et sinon, pour étendre un peu la question de départ, comment nommez-vous vos fonctions et méthodes ? Fan des noms courts à la limite cryptiques de la libc ? ou plus classique en camelCase ou snake_case ? Le premier mot est-il toujours un verbe ou pas forcément ? Êtes-vous fan des pseudo conventions du genre première lettre minuscule = privé, majuscule = public (ça je crois que c’est une spécialité C# et Microsoft en général) ? Pour moi c’est classique et en principe toujours un verbe comme premier mot.

Je souhaite intervenir à nouveau sur le sujet parce que j’ai lu beaucoup de réponses un peu choquantes pour moi. Vous parlez souvent de "pour moi", ou "dans mon code".

Je tiens à rappeler une règle qui me semble être la plus importante: le nommage des variable n’est pas important que pour vous, mais pour toute personne amenée à lire votre code !

Ce qui veut dire que, bien entendu, si le code n’est pas à but de collaboration, vous pouvez utiliser ce qui vous fait le plus plaisir. Sinon il faudra essayer de suivre des conventions. Il en existe dans tous les languages et quasiment toutes les entreprises ont leurs surcouches.

Peu importe ce que tu vas choisir comme méthode, il est important aussi de garder cette même méthode tout au long du script. Rien de plus agaçant d’arriver sur un code avec un peu de camelCase, un peu de snake_case ou autre…