Les identifiants courts sont-ils mauvais? [fermé]

Les identifiants courts sont-ils mauvais? Comment la longueur de l'identifiant est-elle corrélée avec la compréhension du code? Quels autres facteurs (outre la compréhension du code) pourraient être pris en compte pour nommer les identifiants?

Juste pour essayer de maintenir la qualité des réponses, veuillez noter qu'il y a déjà des recherches sur le sujet!

modifier

Curieux que tout le monde ne pense pas que la longueur soit pertinente ou a tendance à préférer des identifiants plus grands, lorsque les deux liens que j'ai fournis indiquent que les grands identifiants sont nuisibles!

Lien brisé

Le lien ci-dessous indique une recherche sur le sujet, mais il est maintenant cassé, je ne semble pas avoir une copie du document avec moi, et je ne me souviens pas de quoi il s'agissait. Je le laisse ici au cas où quelqu'un d'autre le découvrirait.

• http://evergreen.loyola.edu/chm/www/Papers/SCP2009.pdf

La meilleure "règle" que j'ai entendue est que la longueur des noms doit être proportionnelle à la longueur de la portée de la variable. Donc un index iest bien si le corps de la boucle est long de quelques lignes, mais j'aime utiliser quelque chose d'un peu plus descriptif s'il doit être plus long que 15 lignes.

Chaque variable doit avoir une signification, et son nom fait partie de cette signification. Et une partie très importante, car elle aide le lecteur à comprendre à quoi cela sert sans creuser plus profondément l'algorithme. i, jsont évidents à utiliser comme indices, ils sont courts, mais très instructifs. bntest moche closeou closeButtonont du sens. Donc, être court ou long n'est pas le critère le plus important pour le nom de variable, il devrait être significatif. La signification dépend fortement du contexte. Par exemple, vous pouvez donner un nom très court nà la variable de chaîne locale qui est utilisée dans un petit bloc de code, disons 10 lignes et fait référence au nom d'une propriété ( vcar value est un autre exemple).

Les noms de variables doivent donc être informatifs et peu importe qu'ils soient courts ou longs .

J'utiliserai un identifiant qui décrit la variable, quelle que soit sa longueur.

Les cas de i, j et k sont en soi si omniprésents qu'ils se décrivent d'eux-mêmes, vous savez automatiquement que ce sont des indices de boucle. Vous pourriez également dire la même chose pour:

foreach loop (Strings s : myString)

Cependant, les IDE fournissent désormais des outils de complétion de code, de sorte que le seul effet secondaire négatif des identifiants très longs et descriptifs a été supprimé afaik.

Je vais heureusement ajouter et ajouter un mot à un identifiant, si cela est nécessaire pour expliquer le but de la variable.

Ils ne sont pas aussi mauvais que les identifiants trompeurs. Cela ne me dérange pas de déboguer du code dans lequel les identificateurs ne sont qu'une seule lettre, mais au moment où différentes conventions de dénomination entrent en jeu, cela devient ennuyeux. Par exemple, si quelque part vous voyez strPersonID, puis quelque part ailleurs vous voyez s_EmployeeID, alors il est déroutant de dire si ce sont ces deux chaînes et s'il y a une différence. De plus, si les variables sont copiées-collées ( pmapIntString = new std::map<int,int>) et sont totalement erronées, je vais m'inquiéter.

En ce qui me concerne, j'ajoute des commentaires dans le code pour les variables importantes utilisées et j'essaie de maintenir la norme donnée dans les directives de développement. S'il n'y a pas de norme, j'essaie de conserver la même convention de dénomination dans tout le code.

Je lutte...

J'utilise toujours des noms descriptifs comme identifiants, mais récemment j'ai utilisé des identifiants très courts.

Je pense que cela dépend du contexte du code:

• Si vous écrivez des fonctions complexes (algorithmes), utilisez TOUJOURS des identifiants courts (les caractères simples sont les meilleurs)
• Lors de l'écriture de valeurs de paramètres pour les fonctions, utilisez des noms descriptifs.

Je suppose que cela dépend aussi de la densité du code. Parfois, avoir des noms rend la lecture plus difficile.

Parfois sans nom, c'est totalement cryptique!

Je pense qu'ils ne sont pas mauvais en soi, mais ils ne sont pas informatifs à moins qu'ils ne soient très standard.

Les variables de boucle étant donc i, j et k sont si standard qu'il n'y a aucune raison de ne pas les utiliser si vous créez une boucle indexée.

L'autre endroit où j'utiliserai un identifiant très court est quand je déclare une variable temporaire qui sortira du champ d'application dans quelques lignes - la variable temporaire d'une boucle foreach, par exemple. Si ce n'est pas fait référence ailleurs, il est facile pour quiconque lit le code de voir la déclaration et de suivre à quoi elle sert. Si elle doit être utilisée pour plus de cinq ou six lignes, je chercherai à lui donner un nom plus clair.

Au-delà de cela, j'essaie d'utiliser des identificateurs de longueur informatifs - en particulier au niveau de la classe, je veux un identifiant que vous pouvez lire et avoir une idée de la destination de la variable. S'ils deviennent trop longs (et je vois parfois du code avec quatre ou cinq mots enchaînés pour un identifiant), j'ai tendance à considérer cela comme une odeur de code - si j'ai besoin de beaucoup de texte pour distinguer mes variables, est-ce en fait un groupe qui pourrait être mieux stocké dans une table de hachage ou une liste? Pourrais-je créer une sorte d'objet pour modéliser ces données plus précisément? Parfois, vous ne pouvez pas, mais un identifiant très long est un indicateur qu'il y a quelque chose à regarder ici.

Je suis tout à fait d'accord avec les autres réponses ici, mais je voudrais souligner un autre facteur qui, je pense, est souvent négligé. Un bon nom est souvent un nom idiomatique au code. Cela peut être au niveau de la langue, de l'algorithme ou de certains idiomes internes pour la base de code à portée de main. Le fait est que même si le nom ne signifie rien pour quelqu'un qui ne connaît pas le domaine du code, il peut tout de même être le meilleur nom dans le contexte donné.

Nommer une variable est toujours un exercice d'équilibre entre l'unicité et l'intelligibilité. La longueur du nom est liée aux deux, de différentes manières. Les noms plus longs sont plus faciles à rendre uniques; les noms de longueur moyenne ont tendance à être plus compréhensibles que les noms trop courts ou trop longs.

Un nom de variable très court est utile que si elle a une histoire qui le rend compréhensible (par exemple i, j, et kpour les indices, dxune distance le long d' un axe) ou une portée qui est assez petit pour toutes les références soient visibles à la fois (par exemple , temp). Les pires noms de variables au monde sont des choses comme t47. ("Qu'est-ce que cela signifie et pourquoi est-il différent de cela t46?") Dieu merci, le style de dénomination est principalement utilisé avec FORTRAN, mais c'est là que le désir de noms de variables plus longs est enraciné.

Comme le montre votre article d'origine, les noms trop longs sont également difficiles à lire, car de subtiles différences internes peuvent être manquées lorsque l'on regarde le code. (La différence entre DistanceBetweenXAxisAbscissae& DistanceBetweenYAxisAbscissaeest vraiment difficile à comprendre rapidement.)

Comme NoteToSelf l'a souligné précédemment, les exigences d'unicité d'un nom dépendent principalement de l'étendue sur laquelle le nom doit être unique. L'index d'une boucle de 5 lignes peut être i; un index d'un enregistrement actif qui est transmis d'une fonction à une autre devrait avoir un nom beaucoup plus descriptif.

Une variable locale à une fonction peut avoir un petit nom descriptif comme deltaXsans problème. Une variable delta X statique dans un module doit avoir un nom qui distingue ce deltaX des autres deltaX du même module, ce qui le rend plus long. Et une variable globale delta X doit être rendue unique sur tous les modules et tous les autres modules possibles qui peuvent être créés, probablement en concaténant le nom du module à l'autre nom descriptif. C'est l'un des nombreux problèmes avec les mondiaux; pour être utilement uniques, les noms doivent être suffisamment longs pour être difficiles à lire.

Au contraire, je pense que les identifiants longs sont pires que les identifiants courts (sauf si vous avez affaire à des constantes). L'utilisation TheVariableThatHoldsTheCapacityOfMyContainerClassrend votre code beaucoup plus sujet aux erreurs que l'utilisation Capacity.

En soi, les identifiants courts ne sont pas mauvais. Le choix de bons noms (courts ou longs) a pour but de clarifier le code. Il est plus important de choisir des identifiants au service de la clarté du code que de satisfaire à certaines exigences de longueur minimale. En général, cela signifie écrire des noms significatifs légèrement plus longs.

Une observation que j'ai eue au fil des ans et qui l'est moins aujourd'hui qu'elle ne l'était il y a 10 ou 15 ans. Les programmeurs qui ne peuvent pas taper sont ceux qui vous combattront bec et ongles pour les noms variables. Ce sont ceux avec tous les noms de variables de 1 à 3 lettres.

Donc, mon conseil est d'utiliser un nom significatif comme l'ont dit de nombreux commentateurs, puis d'apprendre à taper. J'ai envisagé d'ajouter un test de dactylographie aux entretiens, juste pour voir où se trouvent les gens, mais je commence à voir beaucoup moins de non-dactylographes car les ordinateurs deviennent une partie plus importante de la société.

Le premier article auquel vous vous connectez semble intéressant, mais sa conclusion est qu'ils n'ont trouvé aucune preuve significative pour ou contre l'hypothèse que les "indices de mise à la terre", y compris les noms de variables significatifs, aident à la compréhension du code. Le temps de regard utilisé comme proxy pour la compréhension du code est intéressant, mais pas un slam dunk.

J'ai bien peur d'avoir trouvé le deuxième papier tout simplement idiot. Le premier problème est que les exemples de noms longs qu'ils fournissent sont gratuits et ne fournissent aucune information supplémentaire. Je pense que nous pouvons tous convenir que faire un nom de variable plus long juste pour le rendre plus long est stupide. Leur exemple de nommer une distance_between_abscissae variable plutôt que dx est un homme de paille.

Plus important encore, leur expérience est un test de simple mémorisation plutôt que de compréhension. Il teste la capacité des sujets à remplir les éléments manquants d'un nom de variable lorsqu'ils sont présentés dans une liste sans contexte. Oui, les noms plus longs sont plus difficiles à mémoriser, mais lorsque je code, je ne mémorise pas les noms de variables, je les utilise pour fournir du contexte. Je suppose que vous pourriez faire valoir que la difficulté de se souvenir d'une longue variable rend le code plus difficile à écrire, mais le code est lu beaucoup plus souvent qu'il ne l'est, alors quelle activité devrait être optimisée?

L'une de mes principales mesures pour déterminer si une ligne de code est lisible ou non est de savoir dans quelle mesure un autre contexte provenant d'autres lignes doit être lu pour vraiment être sûr que vous comprenez ce que fait la ligne.

Il est facile de dire que "n'importe qui devrait pouvoir comprendre que i, j et k sont des variables de boucle". Et la plupart du temps, c'est vraiment évident. Mais j'essaie toujours de rester humble et professionnel à ce sujet et de supposer qu'il est facile de faire des erreurs lors de la programmation. Donc, si je fais une boucle dans un tableau de Grobbles, je nommerai la variable de boucle grobbleIndex. Je pourrais également accepter i comme abréviation d'index. Lorsque vous utilisez ij et k, il est plus difficile de détecter les erreurs, comme utiliser le mauvais index avec le mauvais tableau, etc. Et cela devient encore pire lorsque vous avez une boucle intérieure.

PS. Au moment où j'ai écrit cette réponse, je codais du javascript sur un mini-ordinateur portable de 10 pouces avec un écran divisé verticalement dans vim et j'ai encore pris le temps de nommer mes variables de boucle rowIndex et columnIndex.

Dans certaines applications, une variable courte ne peut tout simplement pas expliquer les données de la variable. Court ou long n'est pas pertinent. L'utilisation d'une variable plus longue ne ralentit pas votre code. Bien sûr, il est plus difficile de taper un nom de variable long, mais au moins la personne qui lit le code 6 mois plus tard (qui peut être vous) sera en mesure de comprendre ce qui se passe sans avoir besoin de mettre des traces en supposant que c'est même possible.

Je pense que l'idéal est que les noms soient descriptifs à moins que ...

L'idée que les noms peuvent (peut - être devraient) être plus court - et donc implicitement moins descriptive - si elles ont une portée limitée est seulement une raison de se écarter de l'idéal.

Personnellement, j'utilise fréquemment des noms courts pour un petit nombre d'entités référencées à plusieurs reprises. Par exemple, des sous-programmes spécifiques aux applications.

Je n'utiliserais jamais de noms d'identifiant avec moins de 4-5 caractères, par exemple une variable de boucle pourrait être Index ou jIndex ou kIndex selon le nombre de boucles internes dont j'ai besoin pour accomplir quelque chose, mais pour d'autres noms disons une "clé" que j'utiliserais "String LKey" ou "int LKey", "L" pour local si c'est une variable de méthode ou "F" pour variable de classe privée, tous les autres identifiants comme les autres mentionnés avant moi doivent expliquer la raison de son existence dans son nom, sinon le la portée "identifiant" est inutile n'est-ce pas?!