Gli identificatori brevi sono dannosi? [chiuso]

Gli identificatori brevi sono dannosi? In che modo la lunghezza dell'identificatore è correlata alla comprensione del codice? Quali altri fattori (oltre alla comprensione del codice) potrebbero essere presi in considerazione quando si tratta di nominare gli identificatori?

Solo per cercare di mantenere alta la qualità delle risposte, tieni presente che esiste già qualche ricerca sull'argomento!

modificare

Curioso che tutti non pensino che la lunghezza sia pertinente o tendano a preferire identificatori più grandi, quando entrambi i collegamenti che ho fornito indicano che identificatori di grandi dimensioni sono dannosi!

Collegamento non funzionante

Il link in basso indicava una ricerca sull'argomento, ma ora è rotto, non mi sembra di avere una copia del documento con me e non ricordo di cosa si trattasse. Lo lascio qui nel caso qualcun altro lo capisca.

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

La "regola" migliore che ho sentito è che la lunghezza dei nomi dovrebbe essere proporzionale alla lunghezza dell'ambito della variabile. Quindi un indice iva bene se il corpo del loop è lungo poche righe, ma mi piace usare qualcosa di un po 'più descrittivo se diventa più lungo di 15 righe.

Ogni variabile dovrebbe avere un significato e il suo nome fa parte di quel significato. E una parte molto importante, poiché aiuta il lettore a capire a cosa serve senza scavare più a fondo nell'algoritmo. i, jsono ovvi da usare come indici, sono brevi, ma molto istruttivi. bntè brutto closeo closeButtonsono significativi. Quindi essere breve o lungo non è il criterio più importante per il nome della variabile, dovrebbe essere significativo. La significatività dipende fortemente dal contesto. Ad esempio, puoi dare un nome molto breve come nla variabile stringa locale che viene utilizzata in un piccolo blocco del codice dire 10 righe e si riferisce al nome di una proprietà ( vper valore è un altro esempio).

Quindi i nomi delle variabili dovrebbero 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 da autodescriversi, sai automaticamente che sono indici di loop. Potresti anche dire lo stesso per:

foreach loop (Strings s : myString)

Tuttavia, gli IDE ora forniscono strumenti di completamento del codice, quindi l'unico effetto collaterale negativo di identificatori molto lunghi e descrittivi è stato rimosso in modo definitivo.

Aggiungerò felicemente una parola in più a un identificatore, se è necessario per spiegare lo scopo della variabile.

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

Quando si tratta di me, aggiungo commenti nel codice per le variabili importanti utilizzate e cerco di mantenere lo standard indicato nelle linee guida per lo sviluppo. Se non esiste uno standard, provo a mantenere la stessa convenzione di denominazione in tutto il codice.

Mi sforzo...

Uso sempre nomi descrittivi come identificatori, ma di recente ho usato identificatori molto brevi.

Penso che dipenda dal contesto del codice:

• Se si scrivono funzioni complesse (algoritmi), utilizzare SEMPRE identificatori brevi (i caratteri singoli sono i migliori)
• Quando si scrivono i valori dei parametri per le funzioni, utilizzare nomi descrittivi.

Immagino che dipenda anche dalla densità del codice. A volte avere nomi in realtà rende più difficile la lettura.

A volte senza nomi è totalmente enigmatico!

Il mio pensiero è che non sono cattivi in se stessi ma sono poco informativi a meno che non siano molto standard.

Quindi le variabili di ciclo essendo i, j e k è così standard che non c'è motivo di non usarle se si sta creando un ciclo indicizzato.

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

Oltre a ciò, cerco di utilizzare identificatori di lunghezza informativi, in particolare a livello di classe, voglio un identificatore che puoi leggere e avere un'idea di ciò a cui la variabile è destinata. Se stanno diventando troppo lunghi (e vedo il codice a volte con quattro o cinque parole messe insieme per un identificatore) tendo a considerarlo come 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 archiviato in un hashmap o in un elenco? Potrei creare un qualche tipo di oggetto per modellare questi dati in modo più accurato? A volte non puoi, ma un identificatore molto lungo è un indicatore 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 idiomatico per il codice. Questo può essere a livello di lingua, a livello di algoritmo o in alcuni modi di dire interni per la base di codice a portata di mano. Il punto è che mentre il nome può non significare nulla per qualcuno che non conosce il dominio del codice, può comunque essere il nome migliore in un determinato contesto.

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

Un nome variabile molto breve è utile solo se ha una storia che lo rende comprensibile (ad esempio, i, j, e kper gli indici, dxper una distanza lungo un asse) o un ambito che è abbastanza piccolo per tutti i riferimenti siano visibili contemporaneamente (es , temp). I nomi delle variabili peggiori al mondo sono cose come t47. ("Che cosa significa e perché è diverso da t46?") Grazie al cielo lo stile di denominazione è emerso principalmente con FORTRAN, ma è qui che è radicato il desiderio di nomi di variabili più lunghe.

Come ha mostrato il tuo documento originale, anche i nomi troppo lunghi sono difficili da leggere, poiché si possono perdere sottili differenze interne quando si guarda il codice. (La differenza tra DistanceBetweenXAxisAbscissae& DistanceBetweenYAxisAbscissaeè davvero difficile da capire rapidamente.)

Come sottolineato in precedenza NoteToSelf, i requisiti di unicità di un nome dipendono principalmente dall'ambito su cui deve essere univoco il nome. L'indice di un loop a 5 righe può essere i; un indice di un record attivo che viene passato da una funzione all'altra dovrebbe avere un nome molto più descrittivo.

Una variabile locale in una funzione può avere un piccolo nome descrittivo come deltaXsenza problemi. Una variabile X delta statica in un modulo deve avere un nome che distingue questo deltaX dagli altri deltaX nello stesso modulo, rendendolo più lungo. E una variabile delta X globale deve essere resa unica in tutti i moduli e in tutti i possibili altri moduli che possono essere creati, probabilmente concatenando il nome del modulo con l'altro nome descrittivo. Questo è uno dei tanti problemi con i globali; per essere utilmente univoci, 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 TheVariableThatHoldsTheCapacityOfMyContainerClassrende il codice molto più soggetto agli errori rispetto all'utilizzo Capacity.

Di per sé, gli identificatori brevi non sono male. Lo scopo di scegliere buoni nomi (brevi o lunghi) è al servizio della chiarezza del codice. La scelta di identificatori al servizio della chiarezza del codice è più importante che soddisfare alcuni requisiti di lunghezza minima. In generale ciò significa scrivere nomi leggermente più lunghi.

Un'osservazione che ho avuto nel corso degli anni ed è meno oggi rispetto a 10 o 15 anni fa. I programmatori che non riescono a digitare sono quelli che ti combatteranno con i nomi delle variabili. Sono quelli con tutti i nomi delle variabili di 1-3 lettere.

Quindi il mio consiglio è di usare un nome significativo come molti commentatori hanno detto e poi imparare a scrivere. Ho pensato di aggiungere un test di battitura alle interviste, solo per vedere dove si trovano le persone, ma sto iniziando a vedere molti meno utenti che non scrivono mentre i computer diventano una parte più grande della società.

Il primo documento a cui ci si collega sembra interessante, ma la sua conclusione è che non hanno trovato prove significative a favore o contro l'ipotesi che "suggerimenti di base", compresi nomi di variabili significativi, aiutano nella comprensione del codice. Lo sguardo usato abita il tempo come un proxy per la comprensione del codice che è interessante, ma non una schiacciata.

Temo di aver trovato il secondo documento sciocco. Il primo problema è che gli esempi di nomi lunghi che forniscono sono gratuiti, senza fornire ulteriori informazioni. Penso che possiamo essere tutti d'accordo sul fatto che allungare un nome di variabile solo per allungarlo sia stupido. Il loro esempio di denominazione di 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. Verifica la capacità dei soggetti di riempire i pezzi mancanti di un nome di variabile quando presentati in un elenco senza contesto. Sì, i nomi più lunghi sono più difficili da memorizzare, ma quando sto codificando non memorizzo i nomi delle variabili, li utilizzo per fornire il contesto. Suppongo che potresti sostenere che la difficoltà di ricordare la variabile lunga rende il codice più difficile da scrivere, ma il codice viene letto molto più spesso di quanto sia scritto, quindi quale attività dovrebbe essere ottimizzata?

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

È facile dire che "chiunque dovrebbe essere in grado di capire che i, je k sono variabili di loop". E la maggior parte delle volte è davvero ovvio. Ma cerco ancora di rimanere umile e professionale su questo e presumo che sia facile commettere errori durante la programmazione. Quindi, se eseguo il looping in una matrice di Grobbles, nominerò la variabile loop grobbleIndex. Potrei anche accettare i come abbreviazione di indice. Quando si usano ij e k è più difficile individuare errori come usare l'indice sbagliato con l'array sbagliato e così via. E peggiora ancora quando hai un circuito interno.

PS. Al momento in cui ho scritto questa risposta stavo codificando un po 'di javascript su un mini laptop da 10 "con uno schermo diviso verticalmente in vim e ho ancora preso il tempo di nominare le mie variabili di ciclo rowIndex e columnIndex.

In alcune applicazioni una breve variabile semplicemente non può spiegare i dati nella variabile. Corto o lungo è irrilevante. L'uso di una variabile più lunga non rallenta il codice. Certo, è più difficile scrivere un nome variabile lungo ma almeno la persona che legge il codice 6 mesi dopo (che potresti essere tu) sarà in grado di capire cosa sta succedendo senza dover tracciare supponendo che sia persino possibile.

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

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

Personalmente uso spesso nomi brevi per un numero limitato di entità a cui si fa ripetutamente riferimento. Ad esempio, sottoprogrammi specifici delle app chiamati di frequente.

Non userei mai nomi di identificativi 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 ho bisogno per realizzare qualcosa, ma per altri nomi diciamo una "chiave" che userei "String LKey" o "int LKey", "L" per local se è una variabile di metodo o "F" per una variabile di classe privata, tutti gli altri identificatori come altri menzionati prima di me dovrebbero spiegare il motivo della sua esistenza nel suo nome, altrimenti il L'ambito "identificatore" è inutile, vero ?!