Est-ce une mauvaise pratique de nommer une variable inutilisée avec un seul trait de soulignement?
Souvent, lorsque la syntaxe du langage m'oblige à nommer une variable qui n'est jamais utilisée, je la nomme _.
Dans mon esprit, cela réduit l'encombrement et me permet de me concentrer sur les variables significatives du code. Je le trouve discret, de sorte qu'il produit un effet "hors de vue, hors de l'esprit".
Un exemple courant où je fais cela est de nommer des sous-requêtes en SQL.
SELECT *
FROM
(
SELECT *
FROM TableA
JOIN TableB
ON TableA.ColumnB = TableB.ColumnB
WHERE [ColumnA] > 10
) _ --This name is required, but never used here
ORDER BY ColumnC
Un autre exemple est une variable de boucle qui n'est pas utilisée.
array = [[] for _ in range(n)] # Defines a list of n empty lists in Python
J'utilise cette technique avec parcimonie, uniquement lorsque je sens qu'un nom descriptif n'ajoute rien au code, et en quelque sorte lui enlève en ajoutant plus de noms à retenir. À certains égards, je le vois comme similaire au mot clé var en C #, que j'utilise également avec parcimonie.
Mes collègues ne sont pas d'accord. Ils disent que même avoir un seul nom de caractère (alphabétique) vaut mieux que _.
Ai-je tort? Est-ce une mauvaise pratique de le faire?
Tous les noms doivent avoir un sens. Si _ était une norme bien connue dans votre entreprise ou dans la communauté au sens large, elle aurait alors un sens en tant que "nom sans importance". Sinon, je dirais que c'est une mauvaise pratique. Utilisez un nom descriptif pour ce à quoi vous vous référez, d'autant plus que le nom pourrait être important à l'avenir.
Je dirais que c'est une pratique acceptable. Il s'agit d'un cas rare où je considérerais que la majorité a tort et a besoin de mettre à jour sa connaissance des idées de programmation récentes. Dans de nombreux langages, en particulier les langages fonctionnels basés sur ML comme Haskell et OCaml, il est extrêmement courant d'utiliser _ comme variable "inutilisée". Même Lua, qui n'offre pas de prise en charge explicite du langage, encourage l'utilisation de _ comme espace réservé par convention.
Plusieurs langages (Haskell, Lua et D je pense du haut de ma tête) offrent également une convention où les variables qui commencent par un trait de soulignement ne génèrent pas d'avertissements du compilateur sur les "variables locales inutilisées", ce qui rend _ le nom de variable inutilisé le plus court. Vous pouvez utiliser quelque chose comme _unused mais je suis d'accord avec vous que ça fait juste de l'encombrement.
En Python _ Est définitivement acceptable. Il peut cependant entrer en conflit avec gettext alias _().
Les autres conventions courantes sont dummy, unused; seul ou comme préfixe.
Certains outils d'analyse de code connaissent ces conventions et n'émettront pas d'avertissements de variable inutilisés:
Cela dépend de l'écosystème dans lequel ce code va vivre. Si _ est une norme acceptée pour indiquer "variable fictive"/"sortie inutilisée", puis par tous les moyens, respectez-la. Si ce n'est pas le cas, découvrez ce que c'est et utilisez-le.
Certains langages de programmation (par exemple Haskell) ont même cet identifiant `` spécial '' intégré dans leur syntaxe exactement aux fins que vous mentionnez.
Attention, _ a déjà une signification intrinsèque dans certaines langues
En Python:
9.6. Variables privées et références locales de classe
entrez la description du lien ici Les variables d'instance "privées" auxquelles on ne peut accéder que depuis l'intérieur d'un objet n'existent pas en Python. Cependant, il existe une convention qui est suivie par la plupart des Python: un nom précédé d'un trait de soulignement (par exemple _spam) doit être traité comme une partie non publique de l'API (qu'il s'agisse d'un fonction, une méthode ou un membre de données. Il doit être considéré comme un détail d'implémentation et sujet à changement sans préavis.
Il y a aussi une autre mention dans le PEP 8 (Guide de style pour Python Code):
Descriptif: styles de dénomination
_single_leading_underscore: faible indicateur "usage interne". Par exemple. depuis M import * n'importe pas les objets dont le nom commence par un trait de soulignement.
En C #:
Il est généralement utilisé pour marquer des variables privées qui ont des propriétés publiques/internes. Mais la pratique est généralement méprisée ces jours-ci .
En JavaScript:
Il existe une bibliothèque appelée underscore.js qui utilise le trait de soulignement comme préfixe pour les extensions de prototype non standard.
Exemple:
var object = { some:'stuff' };
var newObject = _.clone(object);
Ce qui m'amène à mon propos. Quel est le problème avec les conventions classiques des variables d'espace réservé.
var i, j, k, l; // iterator placeholders
var x, y, z, xx, yy, zz // value placeholders
var foo, bar, bas, fixx, buzz, qux, etc... // demonstration placeholders
Pourquoi utiliser une convention personnalisée que certains peuvent mal interpréter alors qu'il existe déjà de nombreuses conventions communes?
J'utilise "factice" pour ce genre de chose. Ou "merde", si je teste juste quelque chose :) Nommez vos variables pour décrire ce qu'elles sont. S'ils sont des variables muettes et inutilisées, nommez-les comme tels.
Je trouve que c'est une mauvaise pratique parce que
vous ne devriez pas avoir de variable invisible dans votre code. Si vous pensez que vous devriez, la raison pourrait probablement être discutée.
la langue Go utilise ce mot-clé pour indiquer qu'aucune variable n'est la destination de l'un des multiples retours d'une fonction. Si votre langue n'a pas plusieurs retours, ce n'est pas nécessaire. Votre convention de dénomination vous blessera le jour où vous utiliserez une langue utilisant _ comme notation de langue standard.
(Je ne sais pas Python: cette construction est-elle vraiment nécessaire?)
Il peut être syntaxiquement valide et peut être OK dans le cadre d'une norme.
Cela dit, c'est quelque chose que je demanderais à quelqu'un de changer dans un examen du code. Je ne le mettrais pas non plus dans une norme de codage et j'essaierais de le retirer d'une norme existante. C'est juste plus difficile à lire et pas super significatif.
Je pense que c'est faux parce que:
1) C'est plus difficile à voir car il n'y a pas beaucoup de pixels.
2) S'il y a plus d'un _, comment savez-vous lequel? - ou qu'un nouveau développeur a "suivi les règles" et a gardé son utilisation extrêmement locale?
3) C'est une pratique qui n'est pas utile. L'utilisation de noms de variables à une seule lettre est tellement ancienne (c'est-à-dire mon éducation d'origine!). Je les verrai ... puis je verrai des commentaires ajoutés pour dire ce que fait le code et c'est une mauvaise pratique dans le monde d'aujourd'hui. J'utilise autant que possible des noms de variables longs pour que tout le monde, indépendamment du niveau de programmation ou de la familiarité avec le code, puisse simplement le "lire" presque comme l'anglais. L'utilisation de noms à 1 lettre est une pratique extrêmement courante avec du code plus ancien et avec des programmeurs plus anciens (encore une fois, inclut moi) mais cela ne le rend pas correct.
Pour éviter les collisions d'espace de noms et permettre le débogage, dans le cas où ce nom de variable est votre seul indice, il pourrait être préférable de l'appeler "Join_ab_unused".
Inspiré par Birfl.
Oui, c'est une mauvaise pratique pour deux raisons:
- Préfixer une variable inutilisée avec un trait de soulignement n'est pas une norme largement acceptée. Il sera probablement ignoré les "non initiés".
- J'ai vu certains préfixes variables de membres privés avec un trait de soulignement, et votre norme le ferait grandement confondre ces personnes.
Ce que vous essayez de faire, c'est de coder dans une version plus agréable de SQL qui n'a pas le problème de vous forcer à inventer un nom pour quelque chose d'inutile.
Le trait de soulignement est presque invisible, il semble donc que vous soyez dans cette langue. Si seulement des espaces pouvaient être utilisés comme identifiant, ce serait parfait, non?
Mais vous n'êtes pas dans une langue différente, et ce que vous faites n'est pas un moyen propre de faire une extension de langue.
Cela dépend de la langue. Dans Java, oui, c'est mauvais et cela peut être une tendance dangereuse à ajouter à votre code, en grande partie parce que les outils qui utilisent la réflexion ne gèrent pas très bien les traits de soulignement, car ils sont en dehors de Java conventions de dénomination des variables. En python, c'est aussi mauvais mais pas aussi mauvais. En clojure, c'est 100% correct, et en fait, idiomatique à utilisez les _ comme espaces réservés dans une instruction let.
N'oubliez pas que chaque langue a sa propre syntaxe et son propre ensemble d'expressions idiomatiques, vous devez donc évaluer le bon/mauvais en termes de ces idiomes, plutôt qu'en termes absolus.
Ce serait mauvais en Perl, qui utilise $ _ (et parfois _) comme variable spéciale.
En général, je m'en éloignerais simplement parce que le _ semble être une langue spécifique à la variable. Si je voyais votre code, je serais dans la documentation à la recherche de ce que _, jusqu'à ce que je réalise que ce n'était qu'un mannequin. Rien de mal avec DUMMY, $ DUMMY, peu importe.
J'éviterais les soulignements au début des vars à moins que vous ne soyez certain qu'ils n'ont pas tendance à indiquer autre chose dans un langage ou un cadre donné en usage intensif. Par exemple, en Python, un double soulignement tend à indiquer une var magique. Dans JQuery et d'autres bibliothèques JS, un seul trait de soulignement tend à indiquer une var de secours pour les remplacements d'espace de noms. C'est également une convention de dénomination populaire pour les fichiers d'inclusion qui, à leur tour, ont tendance à être transférés dans le code qui gère les inclusions sous forme var.