Est-ce une mauvaise pratique de nommer une variable inutilisée avec un seul soulignement?


44

Souvent, lorsque la syntaxe du langage exige que je nomme une variable qui n'est jamais utilisée, je le nomme _.

Dans mon esprit, cela réduit l'encombrement et me permet de me concentrer sur les variables significatives du code. Je trouve que c'est discret, de sorte que cela produit un effet "à l'abri des regards".

Un exemple courant de ce que je fais consiste à nommer des sous-requêtes dans 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 j'ai le sentiment qu'un nom descriptif n'ajoute rien au code, et le supprime en quelque sorte en ajoutant plus de noms à retenir. D'une certaine manière, je le vois comme similaire au varmot - clé en C #, que j'utilise aussi avec parcimonie.

Mes collègues ne sont pas d'accord. Ils disent que même avoir un seul nom de caractère (alphabétique) est meilleur que _.

Ai-je tort? Est-ce une mauvaise pratique de faire cela?


4
Je pense que les noms de variables devraient suivre la théorie de l'information, c'est-à-dire que la longueur est la probabilité logarithmique réciproque de leur utilisation (les variables communes ont des noms abrégés). Une seule lettre alphabétique semble être la mauvaise voie à suivre.
dan_waterworth

2
@dan_waterworth L'utilisation de caractères simples ou doubles comme alias de table est une pratique assez courante dans les scripts SQL. Étant donné que vous devez généralement écrire de nombreux [table].[column]identifiants, il est très utile d’utiliser beaucoup de lisibilité [T].[column]. Cela dépend du script bien sûr. Un petit choix comme celui-là convient parfaitement, mais si un script était très volumineux, je pourrais utiliser des noms plus descriptifs.
CodexArcanum

5
Je préférerais que vous utilisiez "factice". Cela me crie qu'ils sont là parce que le langage nécessite une variable qui n'a pas de contexte sémantique en dehors de ces quelques lignes. _ ne lit pas bien à un humain. (une des raisons pour lesquelles je déteste PERL - je ne peux ni le taper ni le lire)
Chris Cudmore

1
Note latérale: Ce que vous nommez est un tableau dérivé , pas une sous-requête.
Nick Chammas

2
Le mot clé var en c # n'a pas cette signification, c'est simplement une déclaration de variable normale dans laquelle le type est déduit.
Francesco De Vittori

Réponses:


60

Tous les noms doivent avoir un sens. Si _était un standard bien connu dans votre entreprise ou dans la communauté au sens large, cela aurait un sens en tant que "nom qui n’a aucune importance". Si ce n'est pas le cas, je dirais que c'est une mauvaise pratique. Utilisez un nom descriptif pour votre référence, d’autant plus que ce nom pourrait avoir une incidence sur l’avenir.


13
+1 dummyserait bien, joined_abserait mieux.
Blrfl

5
+1, il existe une convention selon laquelle je travaille pour utiliser '_' pour les variables non utilisées. Je pense que c'est une bonne convention, mais je suis d'accord avec cette réponse pour le cas du PO. Idéalement, les bases de code devraient avoir l’impression d’être écrites par une seule personne.
dan_waterworth

20
"_" est une norme bien connue avec Python.
Neil G

2
Par contre, si votre société utilise un langage Perl, l’utilisation de $ _ pourrait entraîner un comportement parfois surprenant.
Plutor

2
Dans le prologue, un trait de soulignement indique que la variable sera anonyme et donc inutilisée.
Ivan

44

Je dirais que c'est une pratique acceptable. Il s'agit d'un cas rare où, à mon avis, la majorité aurait tort et aurait 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 tels que Haskell et OCaml, il est extrêmement courant d'utiliser _une variable "non utilisée". Même Lua, qui ne propose pas de prise en charge linguistique explicite, encourage l'utilisation de _placeholder par convention.

Plusieurs langues (Haskell, Lua et DI pensent comme une tête-à-tête) offrent également une convention selon laquelle les variables qui commencent par un trait de soulignement ne génèrent pas d'avertissements du compilateur sur la "variable locale inutilisée", ce qui donne _le nom de variable inutilisé le plus court. Vous pouvez utiliser quelque chose du genre, _unusedmais je suis d’accord avec vous pour dire que cela crée un fouillis.


Dans le cas spécifique de SQL, je l'ai examiné et les collègues peuvent être corrects ici. J'utilise très souvent une seule lettre majuscule pour les alias de table (et souvent R (esults) pour les sous-requêtes). Je pense que l’utilisation de *in select est une très mauvaise chose, car si la table change, votre ensemble de résultats change également de manière inattendue. Il me faut donc généralement un alias à caractère unique pour identifier les colonnes que je sélectionne. Si vous arrêtez d’utiliser *, vous n’avez plus besoin d’un nom "non utilisé".
CodexArcanum

11
À proprement parler, du moins en Haskell, il _s’agit d’un motif et non d’une variable. C'est une différence subtile, mais cela signifie que vous pouvez l'utiliser plusieurs fois, par exemple (x, _, _) = ..., alors qu'essayer de lier plusieurs fois la même variable serait une erreur.
hammar

12

En Python _est définitivement acceptable. Il peut cependant entrer en conflit avec un gettextalias _().

D' autres conventions sont communes dummy, unused; seul ou comme préfixe.

Certains outils d'analyse de code sont conscients de ces conventions et n'émettent pas d'avertissements de variable non utilisés:

  • PyLint pour _oudummy
  • PyDev pour toute variable commençant par _, unusedoudummy

2
De plus, l'utilisation _de variables _nominales en python se heurtera à la dernière valeur renvoyée. Par exemple, dans l'interprète, si vous faites 5*5à la ligne 1; alors sur la ligne 2 _aura la valeur 25. Cependant, si vous le définissez ensuite x,_ = (3,'not used'), vous constaterez qu'il _s'agit maintenant not usedde la dernière valeur renvoyée jusqu'à ce que vous l' ayez trouvée del _. Vous ne devriez probablement pas utiliser la _dernière valeur renvoyée dans du code réel; mais c'est souvent pratique pour l'interprète quand vous essayez de nouvelles choses.
dr jimbob

4
Eh bien, _la dernière valeur renvoyée ne fonctionne que dans le shell interactif.
vartec

La même chose vaut pour Lua. Utiliser _ est une pratique courante
sylvanaar,

11

Cela dépend de l'écosystème dans lequel ce code va vivre. Si _est une norme acceptée pour indiquer "variable factice" / "sortie non utilisée", alors tenez-vous-en à cela. Si ce n'est pas le cas, trouvez ce qui est utilisé et utilisez-le.

Certains langages de programmation (par exemple, Haskell) ont même cet identifiant "spécial" intégré dans leur syntaxe pour les buts que vous mentionnez.


5

Attention, _ a déjà une signification intrinsèque dans certaines langues

En Python:

9.6. Variables privées et références de classe locale

entrez la description du lien ici Les variables d'instance «privées» auxquelles il est impossible d'accéder, sauf de l'intérieur d'un objet, n'existent pas en Python. Cependant, il existe une convention suivie par la plupart des codes 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'une fonction, d'une méthode ou d'un membre de données). . Il doit être considéré comme un détail de la mise en œuvre et sujet à modification sans préavis.

Il existe également une autre mention dans le PEP 8 (Guide de rédaction pour le code Python):

Descriptif: Styles de nommage

_single_leading_underscore: indicateur faible "d'utilisation interne". Par exemple, depuis M import *, les objets dont le nom commence par un trait de soulignement ne sont pas importés.

En C #:

Il est généralement utilisé pour marquer les variables privées ayant 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 point. Quel est le problème avec les conventions de variable d'espace réservé classiques.

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 pourraient mal interpréter alors que de nombreuses conventions communes sont déjà disponibles?


En scala: il s'agit du symbole générique / de marque de réservation, mais vous ne pouvez y faire référence qu'une seule fois .
Rex Kerr

@RexKerr Intéressant. N'hésitez pas à modifier cela dans la réponse si vous le souhaitez. Je voudrais mais je ne suis pas familier avec Scala.
Evan Plaice,

Un commentaire devrait faire. Toute personne utilisant Scala le saurait, et ceux qui n'utilisent pas Scala n'auraient probablement pas la compatibilité Scala en tête de leur liste de raisons de ne pas faire quelque chose.
Rex Kerr

Je pense que l'utilisation d'un de ces espaces réservés "convention" pour les variables inutilisées serait une mauvaise pratique, car cela me ferait penser, d'abord, "pourquoi diable ce type n'a-t-il pas nommé cette chose mieux?" et au bout d’un moment, je découvrais que c’était parce que la variable n’était pas utilisée.
igorsantos07

@ igorsantos07 je suis tout à fait d'accord. Ma préférence serait de donner un nom descriptif, même pour les variables temporaires. Le but de cette réponse est de démontrer pourquoi le soulignement n'est pas un bon choix pour une convention de nommage; en raison de sa signification préexistante dans de nombreuses langues.
Evan Plaice

2

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. Si ce sont des variables factices non utilisées, nommez-les comme telles.


0

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 le faire, la raison pourrait probablement être discutée.

  • la langue utilise ce mot-clé pour indiquer qu’aucune variable n’est la destination de l’un des retours multiples d’une fonction. Si votre langue n'a pas plusieurs déclarations, il n'est pas nécessaire. Votre convention de nommage vous fera mal le jour où vous utiliserez une langue utilisant _ comme notation linguistique standard.

(Je ne connais pas Python: cette construction est-elle vraiment nécessaire?)


2
Si vous l'utilisez pour filtrer plusieurs déclarations, il est également logique de l'utiliser également pour les arguments de fonctions factices. En fait, il n'y a pas beaucoup de différence entre les deux: dans les langages fonctionnels de correspondance de modèles, vous pouvez écrire let (a,b,_) = f(x,y,z)aussi bien que let f(x,y,_) = (g(x),h(x),g(y)), ou peu importe. - Et, oui, il est souvent utile d’avoir des paramètres fictifs: ce n’est pas la seule chose à faire pour une fonction polymorphe ou avec des définitions alternatives assorties à un motif.
gauche autour

1
Votre deuxième point contredit votre point principal: dans Go, cela signifie essentiellement la même chose que "je n’ai aucune utilité pour cette valeur".
Casey Kuball

0

Cela peut être valide du point de vue de la syntaxe, et OK dans le cadre d’une norme.

Cela dit, je demanderais à quelqu'un de modifier le code. De plus, je ne l'inscrirais jamais dans une norme de codage et essayerais de l'enlever d'une norme existante. C'est juste plus difficile à lire, et pas très significatif.


0

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 en a plus d'un _, comment savez-vous lequel? - ou qu'un nouveau développeur a "suivi les règles" et gardé leur utilisation extrêmement locale?

3) C'est une pratique qui n'est pas utile. Utiliser des noms de variable à une seule lettre est une vieille école (c’est-à-dire ma formation initiale!). Je vais les voir ... et ensuite voir les commentaires ajoutés pour dire ce que le code fait et c'est une mauvaise pratique dans le monde d'aujourd'hui. J'utilise autant que possible des noms de variables longs afin que tout le monde, peu importe son niveau de programmation ou sa connaissance du code, puisse simplement "le lire" presque comme l'anglais. Utiliser des noms à une lettre est une pratique extrêmement courante avec les anciens codes et les programmeurs plus âgés (encore une fois, cela m’inclut), mais cela n’a pas un effet positif.


9
"comment savez-vous lequel" vous ne le faites pas : c'est exactement le but, vous n'utilisez pas la variable. Donc, peu importe si _est déjà utilisé dans une portée externe; celle-ci sera alors ombrée (ou quoi que votre langue fasse dans de tels cas), mais aucune d'entre elles n'est réellement utilisée de toute façon.
gauche autour

0

Pour éviter les collisions entre espaces de noms et autoriser le débogage, au cas où ce nom de variable serait votre seul indice, il serait peut-être préférable de l'appeler "join_ab_unused".

Inspiré par Birfl.


0

Oui, c'est une mauvaise pratique pour deux raisons:

  1. Préfixer une variable non utilisée avec un trait de soulignement n'est pas une norme largement acceptée. Il sera probablement ignoré les "non-initiés".
  2. J'ai vu des personnes préfixer les variables membres privés avec un trait de soulignement, et votre standard dérouterait beaucoup ces personnes.

0

Ce que vous essayez de faire est de coder dans une version plus agréable de SQL qui ne vous oblige pas à vous obliger à 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 les 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 d’étendre une extension de langue.


0

Cela dépend de la langue. En java , oui, c’est mauvais et cela peut constituer 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 caractères de soulignement, car ils ne relèvent pas des conventions de nommage des variables java. En python , c'est aussi mauvais, mais pas autant. En clair , son 100% est correct, et en fait, son idiomatique d'utiliser _ comme détenteurs de place dans une déclaration let.

Rappelez-vous que chaque langue a sa propre syntaxe et ses propres idiomes. Vous devez donc évaluer bons / mauvais en termes d'idiotismes plutôt qu'en termes absolus.


5
Je ne suis pas d'accord pour dire que c'est une mauvaise pratique en python. C'est une convention largement comprise
Daenyth

0

Ce serait mauvais en perl, qui utilise $ _ (et parfois _) comme variable spéciale.

En général, je resterais à l’écart juste parce que le _ semble être une langue spécifique. Si je voyais votre code, je serais dans la documentation à la recherche de ce que j’étais, jusqu’à ce que j’ai réalisé que c’était juste un mannequin. Rien de mal avec DUMMY, $ DUMMY, peu importe.


0

J'éviterais les soulignements au début des commandes, à moins que vous ne soyez certains de ne pas avoir tendance à indiquer autre chose dans une langue donnée ou dans un cadre fortement utilisé. Par exemple, en Python, un double trait de soulignement a tendance à indiquer une variable magique. Dans JQuery et d'autres bibliothèques JS, un seul tiret bas tend à indiquer une variable de secours pour les écrasements d'espace de nom. C'est également une convention de nommage populaire pour les fichiers d'inclusion, qui ont tendance à être transférés au code qui gère les inclus sous une forme var.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.