È una cattiva pratica denominare una variabile non utilizzata con un trattino basso singolo?

Question

È una cattiva pratica denominare una variabile non utilizzata con un trattino basso singolo?

#1 da (58 voti)
#2 da (42 voti)
#3 da (12 voti)
#4 da (11 voti)
#5 da (4 voti)
#6 da (2 voti)
#7 da (0 voti)
#8 da (0 voti)
#9 da (0 voti)
#10 da (0 voti)
#11 da (0 voti)
#12 da (0 voti)
#13 da (0 voti)
#14 da (0 voti)
#15 da (0 voti)

42

Spesso quando la sintassi della lingua mi richiede di nominare una variabile che non viene mai utilizzata, la chiamerò _ .

Nella mia mente, questo riduce il disordine e mi consente di concentrarmi sulle variabili significative del codice. Trovo che sia discreto in modo da produrre un effetto "lontano dagli occhi, lontano dalla mente".

Un esempio comune di dove faccio questo è nominare sottoquery in 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 altro esempio è una variabile di ciclo che non viene utilizzata.

array = [[] for _ in range(n)] # Defines a list of n empty lists in Python

Uso questa tecnica con molta parsimonia, solo quando sento che un nome descrittivo non aggiunge nulla al codice, e in un certo senso lo toglie aggiungendo altri nomi da ricordare. Per certi versi la vedo simile alla parola chiave var in C #, che uso anche con parsimonia.

I miei colleghi non sono d'accordo. Dicono che anche avere un singolo nome di carattere (alfabetico) è migliore di _ .

Mi sbaglio? È una cattiva pratica fare questo?

language-agnostic readability variables naming

posta Kris Harper 04.05.2012 - 14:56

fonte

15 risposte

Leggi altre domande sui tag language-agnostic readability variables naming

Iniziare una frase con un nome di funzione? [chiuso] Gli spazi bianchi negli identificatori sono mai stati idiomatici? [chiuso]

score 58 · Answer 1

Tutti i nomi dovrebbero essere significativi. Se _ fosse uno standard ben noto nella tua azienda o nella più ampia comunità, sarebbe significativo come un "nome che non ha importanza". Se non lo è, direi che è una cattiva pratica. Utilizza un nome descrittivo per ciò a cui fai riferimento, soprattutto perché il nome potrebbe importare in futuro.

score 42 · Answer 2

Direi che è una pratica accettabile. Questo è un raro caso in cui considererei la maggioranza sbagliata e bisognosa di aggiornare la propria conoscenza delle recenti idee di programmazione. In molte lingue, in particolare nei linguaggi funzionali basati su ML come Haskell e OCaml, è estremamente comune usare _ come variabile "non usata". Anche Lua, che non offre supporto esplicito per la lingua, incoraggia l'uso di _ come segnaposto per convenzione.

Diverse lingue (Haskell, Lua e DI pensano in cima alla mia testa) offrono anche una convenzione in cui le variabili che portano a un trattino basso non generano avvisi del compilatore su "variabile locale inutilizzata" che rende _ il nome della variabile inutilizzato più breve. Potresti usare qualcosa come _unused , ma sono d'accordo con te sul fatto che faccia solo confusione.

score 12 · Answer 3

In Python _ è definitivamente accettabile. Può comunque essere in conflitto con gettext alias _() .

Altre convenzioni comuni sono dummy , unused ; da solo o come prefisso.

Alcuni strumenti di analisi del codice sono a conoscenza di queste convenzioni e non emetteranno avvisi di variabili inutilizzate:

PyLint per _ o dummy
PyDev per qualsiasi variabile che inizi con _ , unused o dummy

score 11 · Answer 4

Dipende dall'ecosistema in cui questo codice vivrà. Se _ è uno standard accettato per indicare "variabile fittizia" / "output inutilizzato", quindi con tutti i mezzi, attenersi ad esso. Se non lo è, scopri cosa è e usalo.

Alcuni linguaggi di programmazione (ad es. Haskell) hanno persino questo identificatore "speciale" incorporato nella loro sintassi esattamente per gli scopi che hai citato.

score 4 · Answer 5

Attento, _ ha già un significato intrinseco in alcune lingue

In Python:

9.6. Private Variables and Class-local References

enter link description here“Private” instance variables that cannot be accessed except from inside an object don’t exist in Python. However, there is a convention that is followed by most Python code: a name prefixed with an underscore (e.g. _spam) should be treated as a non-public part of the API (whether it is a function, a method or a data member). It should be considered an implementation detail and subject to change without notice.

C'è anche un'altra menzione nel PEP 8 (Style Guide for Python Code):

Descriptive: Naming Styles

_single_leading_underscore: weak "internal use" indicator. E.g. from M import * does not import objects whose name starts with an underscore.

In C #:

Generalmente è usato per marcare variabili private che hanno proprietà pubbliche / interne. Ma in questi giorni la pratica è generalmente guardata in basso .

In JavaScript:

C'è una libreria chiamata underscore.js che usa il carattere di sottolineatura come prefisso per le estensioni prototipo non standard.

Esempio:

var object = { some:'stuff' };
var newObject = _.clone(object);

Il che mi porta al punto. Cosa c'è di sbagliato nelle convenzioni classiche sulle variabili segnaposto.

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

Perché utilizzare una convenzione personalizzata che alcuni potrebbero erroneamente interpretare quando sono già disponibili numerose convenzioni comuni?

score 2 · Answer 6

2

Uso "dummy" per quel genere di cose. O "merda", se sto solo testando qualcosa :) Nome le tue variabili per descrivere quello che sono. Se sono variabili fittizie e non utilizzate, assegnale loro il nome.

risposta data 04.05.2012 - 17:01

fonte

score 0 · Answer 7

Trovo che sia una cattiva pratica perché

non dovresti avere una variabile invisibile nel tuo codice. Se ritieni che la ragione potrebbe essere probabilmente discussa.
la lingua Go utilizza questa parola chiave per indicare che nessuna variabile è la destinazione di uno dei molteplici ritorni di una funzione. Se la tua lingua non ha più resi non è necessaria. La tua convenzione di denominazione ti farà male il giorno in cui userai una lingua usando _ come notazione in linguaggio standard.

(Non conosco Python: questo costrutto è davvero necessario?)

score 0 · Answer 8

Potrebbe essere sintatticamente valido e potrebbe essere OK come parte di uno standard.

Detto questo, è qualcosa che chiederei a qualcuno di cambiare in una revisione del codice. Inoltre, non lo inserisco mai in uno standard di codifica e proverei a rimuoverlo da uno esistente. È solo più difficile da leggere e non super significativo.

score 0 · Answer 9

Penso che sia sbagliato perché:

1) È difficile vedere come non ci siano molti pixel.

2) Se c'è più di un% di_, come fai a sapere quale? - o che un nuovo sviluppatore ha "seguito le regole" e ha mantenuto il loro uso estremamente locale nell'ambito?

3) È una pratica che non è utile. Usare nomi variabili a lettera singola è così vecchia scuola (ad esempio, la mia educazione originale!). Li vedrò ... e poi vedrai i commenti aggiunti per dire cosa fa il codice e questa è una cattiva pratica nel mondo di oggi. Io uso il più possibile nomi di variabili lunghe in modo che tutti, indipendentemente dal livello di programmazione o dalla familiarità con il codice, possano semplicemente "leggerlo" quasi come in inglese. L'uso di 1 lettera è una pratica estremamente comune con codice precedente e con programmatori precedenti (di nuovo, include me), ma non è ok.

score 0 · Answer 10

0

Per evitare collisioni nello spazio dei nomi e consentire il debug, nel caso in cui quel nome di variabile sia l'unico indizio, potrebbe essere meglio chiamarlo "united_ab_unused".

Ispirato da Birfl.

risposta data 04.05.2012 - 18:42

fonte

score 0 · Answer 11

Sì, è una cattiva pratica per due motivi:

Il prefisso di una variabile non utilizzata con un carattere di sottolineatura non è uno standard ampiamente accettato. Sarà probabilmente ignorato il "non iniziato".
Ho visto il prefisso di alcune persone variabili membro private con un carattere di sottolineatura e il tuo standard molto confonderà tali persone.

score 0 · Answer 12

Quello che stai cercando di fare è codificare una versione più carina di SQL che non ha il problema di costringerti a inventare un nome per qualcosa di inutile.

Il trattino basso è quasi invisibile, quindi sembra che tu sia in quella lingua. Se solo uno spazio bianco potesse essere usato come identificatore, sarebbe perfetto, vero?

Ma non sei in una lingua diversa e quello che stai facendo non è un modo pulito per creare un'estensione linguistica.

score 0 · Answer 13

Dipende dalla lingua. In java , sì, questo è negativo e può essere una tendenza pericolosa da aggiungere al codice, soprattutto perché gli strumenti che usano la reflection non gestiscono i caratteri di sottolineatura molto bene, poiché sono al di fuori delle convenzioni di denominazione delle variabili java. In python , anche questo è negativo ma non altrettanto grave. In clojure , è corretto al 100% e, di fatto, è idiomatico usare _s come segnaposto in una dichiarazione let.

Ricorda che ogni lingua ha una sua intera sintassi e un insieme di idiomi, quindi devi valutare il buono / cattivo in termini di questi idiomi, piuttosto che in termini assoluti.

score 0 · Answer 14

Questo sarebbe male in perl, che usa $ _ (e talvolta _) come variabile speciale.

In generale, starei alla larga solo perché il _ sembra essere un linguaggio specificabile. Se vedessi il tuo codice, sarei nella documentazione alla ricerca di cosa fosse, fino a quando ho capito che era solo un manichino. Niente di male in DUMMY, $ DUMMY, qualunque cosa.

score 0 · Answer 15

Eviterei i caratteri di sottolineatura all'inizio di vars a meno che non si fosse certi che non tendessero a indicare qualcos'altro in una data lingua o in un contesto pesante. Ad esempio, in Python, una doppia sottolineatura tende ad indicare una magia var. In JQuery e in altre librerie JS un singolo carattere di sottolineatura tende ad indicare una variabile di fallback per le sovrascritte di namespace. È anche una convenzione di denominazione popolare per includere i file che a loro volta tendono a riportarsi al codice che include le maniglie in formato var.