Gli identificatori brevi sono cattivi? [chiuso]

La migliore "regola" che ho sentito è che le lunghezze dei nomi dovrebbero essere proporzionali alla lunghezza dell'ambito della variabile. Quindi un indice i va bene se il corpo del ciclo è lungo alcune righe, ma mi piace usare qualcosa di un po 'più descrittivo se diventa più lungo di 15ish lines.

Ogni variabile dovrebbe avere un significato e il suo nome è una parte di quel significato. E una parte molto importante, poiché aiuta il lettore a capire a cosa serve senza approfondire l'algoritmo. i , j sono ovvi da utilizzare come indici, sono brevi, ma molto istruttivi. bnt è brutto, close o closeButton sono significativi. Quindi essere breve o lungo non è il criterio più importante per il nome della variabile, dovrebbe essere significativo. La significatività dipende strongmente dal contesto. Ad esempio, puoi dare un nome molto breve come n alla variabile di stringa locale che viene usata in un piccolo blocco del codice, diciamo 10 righe e si riferisce al nome di una proprietà ( v per valore è un altro esempio) .

Quindi i nomi delle variabili devono essere informativi e non importa che siano brevi o lunghi .

Userò un identificatore che descrive la variabile, indipendentemente dalla lunghezza.

I casi di i, j e k sono di per sé così onnipresenti che si auto descrivono, si sa automaticamente che sono indici di loop. Si potrebbe anche dire lo stesso per:

foreach loop (Strings s : myString)

Tuttavia, IDE ora fornisce strumenti di completamento del codice in modo che l'unico effetto collaterale negativo degli identificatori molto lunghi e descrittivi sia stato rimosso afaik.

aggiungerò volentieri parole extra a un identificatore, se necessario per spiegare lo scopo della variabile.

Non sono così male come gli identificatori fuorvianti. Non mi interessa il debug del codice in cui gli identificatori sono solo una lettera, ma nel momento in cui le convenzioni di denominazione diverse entrano in scena diventa fastidioso. Ad esempio, se da qualche parte vedi strPersonID , e poi da qualche altra parte vedi s_EmployeeID , allora è confuso dire se sono entrambe le stringhe e se c'è qualche differenza. Inoltre, se le variabili sono incollate sulla copia ( pmapIntString = new std::map<int,int> ) e sono completamente sbagliate, mi preoccuperò.

Quando si tratta di me, aggiungo commenti nel codice per le variabili importanti utilizzate e cerco di mantenere lo standard fornito nella linea guida dello sviluppo. Se non esiste uno standard, cerco di mantenere la stessa convenzione di denominazione in tutto il codice.

Mi sforzo ...

Uso sempre i nomi descrittivi come identificatori, ma ultimamente ho usato identificatori molto brevi.

Penso che dipenda dal contesto del codice:

• Se il tuo complesso di scrittura funziona (algoritmi), quindi utilizzare SEMPRE identificatori brevi (i singoli caratteri sono i migliori)
• Quando si scrivono i valori dei parametri per le funzioni si usano nomi descrittivi.

Penso che dipenda anche da quanto è denso il codice. A volte avere dei nomi rende più difficile la lettura.

A volte senza nomi è assolutamente criptico!

Il mio pensiero è che non sono cattivi di per sé, ma non sono informativi a meno che non siano molto standard.

Quindi le variabili di ciclo che sono i, j e k sono così standard che non vi è alcun motivo per non usarle se si sta creando un ciclo indicizzato.

L'altro posto dove userò un identificatore molto breve è quando sto dichiarando una variabile temporanea che andrà fuori campo in poche righe di tempo, ad esempio la variabile temporanea da un ciclo foreach. Se non verrà indirizzato altrove, sarà facile per chiunque leggere il codice per vedere la dichiarazione e seguire a cosa serve. Se verrà utilizzato per più di cinque o sei righe, però, cercherò di dargli un nome più chiaro.

Oltre a ciò, cerco di utilizzare identificatori di lunghezza informativa, in particolare a livello di classe, voglio un identificatore che puoi leggere e avere un'idea di cosa è la variabile. Se stanno diventando troppo lunghi (e vedo codice a volte con quattro o cinque parole legate insieme per un identificatore) Tendo a considerarlo un odore di codice - se ho bisogno di così tanto testo per distinguere le mie variabili sono in realtà un gruppo che potrebbe essere meglio conservato in una hashmap o lista? Potrei creare qualche tipo di oggetto per modellare questi dati in modo più accurato? A volte non è possibile, ma un identificatore molto lungo indica che c'è qualcosa che vale la pena guardare qui.

Sono molto d'accordo con le altre risposte qui, ma vorrei sottolineare un altro fattore che penso sia spesso trascurato. Un buon nome è spesso idioma al codice. Questo può essere a livello di linguaggio, livello di algoritmo o alcuni idiomi interni per il codice base disponibile. Il punto è che mentre il nome potrebbe non significare nulla per qualcuno che non conosce il dominio del codice, potrebbe comunque essere il nome migliore nel contesto dato.

Il nome di una variabile è sempre un esercizio per bilanciare l'unicità e la comprensibilità. La lunghezza del nome è correlata ad entrambi, in modi diversi. I nomi più lunghi sono più facili da rendere unici; i nomi di lunghezza media tendono ad essere più comprensibili rispetto ai nomi troppo brevi o troppo lunghi.

Un nome di variabile molto breve è utile solo se ha una cronologia che lo rende comprensibile (es. i , j , & k per indici; dx per una distanza lungo un asse) o un ambito sufficientemente piccolo per poter visualizzare tutti i riferimenti contemporaneamente (ad es. temp ). I peggiori nomi di variabili nel mondo sono cose come t47 . ("Che cosa vuol dire e perché è diverso da t46 ?") Grazie al cielo, lo stile di denominazione è uscito per lo più con FORTRAN, ma è qui che viene radicato il desiderio di nomi di variabili più lunghi.

Come dimostrato dal tuo articolo originale, anche i nomi troppo lunghi sono difficili da leggere, in quanto è possibile non notare le sottili differenze interne quando si guarda il codice. (La differenza tra DistanceBetweenXAxisAbscissae e DistanceBetweenYAxisAbscissae è davvero difficile da raccogliere rapidamente.)

Come notato da NoteToSelf in precedenza, i requisiti per l'unicità di un nome dipendono principalmente dall'ambito il cui nome deve essere univoco. L'indice di un ciclo a 5 linee può essere i ; un indice di un record attivo passato dalla funzione alla funzione avrebbe avuto un nome molto più descrittivo.

Una variabile locale a una funzione può avere un piccolo nome descrittivo come deltaX senza problemi. Una variabile delta X statica in un modulo deve avere un nome che distingue questo deltaX da altri deltaX nello stesso modulo, rendendolo più lungo. E una variabile delta X globale deve essere resa univoca tra tutti i moduli e tutti i possibili altri moduli che possono essere creati, probabilmente concatenando il nome del modulo all'altro nome descrittivo. Questo è uno dei molti problemi con i globals; per essere utilmente unici i nomi devono essere abbastanza lunghi da renderli difficili da leggere.

Al contrario, penso che gli identificatori lunghi siano peggiori degli identificatori brevi (a meno che non si tratti di costanti). L'utilizzo di TheVariableThatHoldsTheCapacityOfMyContainerClass rende il tuo codice molto più soggetto a errori rispetto all'utilizzo di Capacity .

In e di loro stessi, gli identificatori brevi non sono male. Lo scopo di scegliere i nomi di qualità (brevi o lunghi) è in funzione della chiarezza del codice. La scelta degli identificatori al servizio della chiarezza del codice è più importante del rispetto di alcuni requisiti minimi di lunghezza. In generale, ciò significa scrivere nomi leggermente più significativi.

Un'osservazione che ho avuto nel corso degli anni ed è meno così oggi rispetto a 10 o 15 anni fa. I programmatori che non possono digitare sono quelli che ti batteranno a denti stretti per la denominazione delle variabili. Sono quelli con tutti i nomi delle variabili da 1 a 3.

Quindi il mio consiglio è usare un nome significativo come molti commentatori hanno detto e poi imparare a digitare. Ho pensato di aggiungere un test di digitazione alle interviste, solo per vedere dove sono le persone, ma sto iniziando a vedere molto meno dei non-dattilografi quando i computer diventano una parte più grande della società.

Il primo articolo a cui si fa riferimento sembra interessante, ma la sua conclusione è che non hanno trovato prove significative a favore o contro l'ipotesi che "suggerimenti fondanti", compresi i nomi di variabili significative, aiutano nella comprensione del codice. Lo sguardo usato dimora il tempo come proxy per la comprensione del codice che è interessante, ma non una schiacciata.

Temo di aver trovato il secondo foglio semplicemente sciocco. Il primo problema è che gli esempi di nomi lunghi forniti sono gratuiti, senza fornire ulteriori informazioni. Penso che tutti possiamo essere d'accordo sul fatto che rendere un nome variabile più lungo solo per renderlo più lungo è stupido. Il loro esempio di nominare una variabile distance_between_abscissae piuttosto che dx è un uomo di paglia.

Ancora più importante, il loro esperimento è un test di semplice memorizzazione piuttosto che di comprensione. Mette alla prova la capacità dei soggetti di riempire pezzi mancanti di un nome di variabile quando presentati in un elenco con il contesto no . Sì, i nomi più lunghi sono più difficili da memorizzare, ma quando sto codificando non memorizzo nomi variabili, li uso per fornire contesto. Suppongo che potresti obiettare che la difficoltà di ricordare una variabile lunga rende il codice più difficile da scrivere, ma il codice viene letto molto più spesso di quanto non sia scritto, quindi quale attività dovrebbe essere ottimizzata?

Una delle mie principali metriche per determinare se una riga di codice è leggibile o meno è quanto deve essere letto molto altro contesto da altre righe per essere veramente sicuro di capire cosa sta facendo la linea.

È facile dire che "chiunque dovrebbe essere in grado di capire che i, jk sono variabili di loop". E la maggior parte delle volte è davvero ovvio. Ma continuo a cercare di rimanere umile e professionale a questo proposito e ritengo che sia facile commettere errori durante la programmazione. Quindi, se eseguo il looping di un array di Grobbles, chiamerò la variabile loop grobbleIndex. Potrei anche accettare i come abbreviazione di indice. Quando si utilizza i j e k è più difficile individuare errori come l'utilizzo dell'indice sbagliato con l'array sbagliato e così via. E diventa ancora peggio quando hai un ciclo interno.

PS. All'epoca in cui ho scritto questa risposta stavo codificando un javascript su un mini laptop da 10 "con uno schermo diviso verticalmente in vim e ho comunque impiegato del tempo per nominare le variabili di loop rowIndex e columnIndex.

In alcune applicazioni una variabile breve semplicemente non può spiegare i dati nella variabile. Breve o lungo è irrilevante. L'utilizzo di una variabile più lunga non rallenta il codice. Certo è più fatica a digitare un nome variabile lungo, ma almeno la persona che legge il codice 6 mesi dopo (che potrebbe essere tu) sarà in grado di capire cosa sta succedendo senza bisogno di mettere le tracce presumendo che sia persino possibile. p>     

Penso che l'ideale sia che i nomi siano descrittivi a meno che ...

L'idea che i nomi possano (forse dovrebbero) essere più brevi - e quindi implicitamente meno descrittivi - se hanno un ambito limitato è solo una una ragione per deviare dall'ideale.

Personalmente uso spesso nomi brevi per un piccolo numero di entità con riferimenti ripetuti. Per esempio, le subroutine specifiche dell'app, ad esempio.

Non utilizzerei mai nomi di identificatori con meno di 4-5 caratteri, ad esempio una variabile di ciclo potrebbe essere Index o jIndex o kIndex a seconda di quanti loop interni devo eseguire qualcosa, ma per altri nomi diciamo una "chiave" Userei "String LKey" o "int LKey", "L" per local se è una variabile di metodo o "F" per la variabile di classe privata, tutti gli altri identificatori come gli altri prima di me dovrebbero spiegare la ragione della sua esistenza nel suo nome , altrimenti lo scope "identificatore" è inutile vero?!