C'è una scusa per i nomi di variabili brevi?


140

Questo è diventato una grande frustrazione con la base di codice in cui sto attualmente lavorando; molti dei nostri nomi di variabili sono brevi e non descrittivi. Sono l'unico sviluppatore rimasto sul progetto e non c'è documentazione su ciò che la maggior parte di loro fa, quindi devo dedicare tempo extra a rintracciare ciò che rappresentano.

Ad esempio, stavo leggendo un codice che aggiorna la definizione di una superficie ottica. Le variabili impostate all'inizio erano le seguenti:

double dR, dCV, dK, dDin, dDout, dRin, dRout
dR = Convert.ToDouble(_tblAsphere.Rows[0].ItemArray.GetValue(1));
dCV = convert.ToDouble(_tblAsphere.Rows[1].ItemArray.GetValue(1));
... and so on

Forse sono solo io, ma essenzialmente non mi ha detto nulla di ciò che rappresentavano, il che ha reso difficile la comprensione del codice. Tutto quello che sapevo era che si trattava di una variabile analizzata su una riga specifica da una tabella specifica, da qualche parte. Dopo alcune ricerche, ho scoperto cosa significano:

dR = radius
dCV = curvature
dK = conic constant
dDin = inner aperture
dDout = outer aperture
dRin = inner radius
dRout = outer radius

Li ho rinominati essenzialmente in quello che ho lassù. Allunga alcune linee, ma penso che sia un giusto scambio. Questo tipo di schema di denominazione viene tuttavia utilizzato in gran parte del codice. Non sono sicuro che si tratti di un artefatto da parte degli sviluppatori che hanno imparato lavorando con sistemi più vecchi o se c'è un motivo più profondo dietro di esso. C'è una buona ragione per nominare le variabili in questo modo o sono giustificato aggiornandole a nomi più descrittivi quando li incontro?


98
Mi sembra che, in quel caso specifico, si tratti di nomi di variabili copiati direttamente da una formula matematica longhand.
Dave Nay,


35
Se non riesci a capire il codice matematico a causa dei nomi di variabili brevi, tieni presente che potrebbe essere perché non capisci la matematica, non perché i nomi sono troppo brevi. Modificare le espressioni matematiche che non capisci non è un processo ad alta affidabilità. Una volta compresa la matematica, la lunghezza dei nomi delle variabili è irrilevante. Fai un favore agli altri e lascia una citazione (in un commento) a qualche descrizione pertinente della matematica, se dovessi impararla!
Rex Kerr,

3
Qualsiasi identificatore che prende il nome Donkey Kong è approvato: dK = conic constant.
Thomas Eding,

8
Al contrario, ci si potrebbe chiedere se l'ignoranza del campo di dominio giustifica ignorare le sue convenzioni. Alla fine, dipende dal contesto.
Daniel C. Sobral,

Risposte:


234

Sembra che questi nomi di variabili si basino sulle abbreviazioni che ti aspetteresti di trovare in un libro di testo di fisica che risolve vari problemi di ottica. Questa è una delle situazioni in cui nomi di variabili brevi sono spesso preferibili a nomi di variabili più lunghi. Se hai fisici (o persone che sono abituate a elaborare le equazioni a mano) che sono abituati a usare abbreviazioni comuni come Rin, Rout, ecc., Il codice sarà molto più chiaro con quelle abbreviazioni di quanto non lo sarebbe con nomi di variabili più lunghi. Inoltre, rende molto più semplice confrontare le formule di documenti e libri di testo con il codice per assicurarsi che il codice stia effettivamente eseguendo correttamente i calcoli.

Chiunque abbia familiarità con l'ottica riconoscerà immediatamente qualcosa come Rin come raggio interno (in un documento di fisica, inverrebbe visualizzato come un indice), Rout come raggio esterno, ecc. Sebbene quasi sicuramente sarebbero in grado di tradurre mentalmente qualcosa come innerRadiusper la nomenclatura più familiare, farlo renderebbe il codice meno chiaro a quella persona. Sarebbe più difficile individuare casi in cui una formula familiare fosse stata codificata in modo errato e renderebbe più difficile la traduzione di equazioni in codice da e verso le equazioni che troverebbero in un documento o in un libro di testo.

Se sei l'unica persona che abbia mai visto questo codice, non dovrai mai tradurre tra il codice e un'equazione ottica standard, ed è improbabile che un fisico abbia mai bisogno di guardare il codice in futuro, forse lo fa ha senso rifattorizzare perché il vantaggio delle abbreviazioni non supera più il costo. Se questo fosse un nuovo sviluppo, tuttavia, avrebbe quasi certamente senso usare le stesse abbreviazioni nel codice che troveresti in letteratura.


17
E se non ci sono fisici o matematici nello staff? Il codice è stato essenzialmente lasciato a me. È in gran parte privo di documenti. Sarebbe più difficile leggere i nomi descrittivi?
KChaloux,

127
+1 Non è irragionevole aspettarsi che un programmatore capisca il dominio in cui sta lavorando. D'altra parte, nelle opere matematiche, le variabili sono di solito definite in un posto conveniente. In un codice come questo mi aspetterei un commento importante che mostri la forma lunga.
Karl Bielefeldt,

15
+1: Quello che stai sostanzialmente dicendo è che un programmatore che capisce il dominio in cui sta lavorando capirà i nomi delle variabili. Questo sarà lo stesso in molti progetti anche con nomi di variabili più lunghi. per esempio. una variabile nominata columnin un gioco di strategia militare molto probabilmente significa qualcosa di diverso rispetto a quanto farebbe con il software di creazione di grafici.
Steven Evers,

23
Nella programmazione medica troverai spesso termini che persistono nella sfera della programmazione. Ad esempio con l'oftalmologia vedrai OU, OD e OS. Indicano quale occhio, ad esempio ouSphere, può fare riferimento al componente 'sfera' di una prescrizione di occhiali per l'occhio destro. Sarai un programmatore migliore se capisci il dominio aziendale per cui stai programmando.
Bill

11
+1 per notare i nomi abbreviati che corrispondono a quelli nelle equazioni e formule di documenti e testi. Quando lo faccio, includo i commenti su dove trovare il materiale di riferimento originale.
Jay Elston,

89

Le variabili con tempi di vita brevi dovrebbero essere nominate a breve. Ad esempio, non scrivi for(int arrayCounter = 0; arrayCounter < 10; arrayCounter++) { .... Invece, usi for(int i ....

In generale, si potrebbe dire che più corto è il campo di applicazione variabile, più breve dovrebbe essere il nome. I contatori di loop sono spesso solo singole lettere, diciamo i, je k. Le variabili locali sono qualcosa come baseo frome to. Le variabili globali sono quindi un po 'più elaborate, ad esempio EntityTablePointer.

Forse una regola come questa non viene seguita con la base di codice con cui lavori. È una buona ragione per fare un po 'di refactoring!


14
i, j e k per gli indici di array rappresentano una tradizione che risale almeno a Fortran. Qualsiasi programmatore che si rispetti avrà familiarità con questa convenzione.
Dominic Cronin,

7
Io di solito non scrivo i, j, k, scrivo qualcosa di simile personPos, perché allora io non dimenticherò quello che sto iterazione su e ciò che l'indice rappresenti.
Malcolm,

18
-1, utilizzo nomi lunghi per le iterazioni dell'indice di array, ma do loro un nome significativo anziché ovvio e insignificante arrayCounter . Rende il codice più facile da leggere e almeno ti evita di calpestare tutto il contatore esterno quando copi / incolli un altro ciclo all'interno di questo.
Oleg V. Volkov,

3
counter è un sostantivo o un aggettivo. Count è un sostantivo o un verbo. Certo, ancora non avrebbe chiamato qualcosa arrayCounter, mi piacerebbe utilizzare personIndexo rowo quello descritto quello che sto guardando.
Wayne Werner,

6
Quando faccio un singolo loop, lo uso i. Ma non appena passo a un ciclo nidificato, lascio cadere la inomenclatura. La ragione di ciò è perché voglio davvero tenere traccia di quale variabile di ciclo si sta lavorando, e ivs jpuò essere abbastanza ingannevole nel codice denso. Renderlo più leggibile e aggiungere più spazi bianchi è intrinsecamente necessario per me.
jcolebrand,

48

Il problema con il codice non sono i nomi abbreviati, ma piuttosto la mancanza di un commento che spieghi le abbreviazioni o che indichi alcuni materiali utili sulle formule da cui derivano le variabili.

Il codice assume semplicemente la familiarità del dominio problematico.

Va bene, dal momento che è probabilmente richiesta la familiarità nel dominio del problema per comprendere e mantenere il codice, specialmente nel ruolo di qualcuno che lo "possiede", quindi ti conviene acquisire la familiarità piuttosto che aggirare i nomi allungati.

Ma sarebbe bello se il codice fornisse alcuni suggerimenti per fungere da trampolini. Anche un esperto di dominio potrebbe dimenticare che dKè una costante conica. Aggiungere un piccolo "cheat sheet" in un blocco di commenti non farebbe male.


Alla fine è finito con qualcosa del genere.
KChaloux,

5
Questo è sbagliato. Non c'è motivo di rendere il tuo codice difficile da leggere per costringere le persone a dedicare più tempo a "impararlo". Non stai insegnando, stai solo rallentando le persone. Inoltre, non esiste praticamente mai un solo proprietario di codice per sempre. Sei miope ed egoista.
xaxxon,

7
È la tua interpretazione che è sbagliata, non la risposta. Il codice implementa alcuni calcoli che esistono al di fuori di quel codice e indipendentemente da esso, e che sono venuti prima del codice. Mantenere la stessa denominazione è utile. Qualcuno che mantiene il codice dovrà probabilmente studiare quella matematica esterna e non dover mappare tra due schemi di denominazione aiuterà quella persona.
Kaz,

19

Per alcune variabili che sono ben note nel dominio problematico - come nel caso che hai qui - i nomi delle variabili concise sono ragionevoli. Se sto lavorando a un gioco, voglio che le mie entità di gioco abbiano variabili di posizione xe y, non horizontalPositione verticalPosition. Allo stesso modo contatori di ciclo che non hanno alcuna semantica di là di indicizzazione, mi aspetto di vedere i, j, k.


Direi che cv, din e dout non sono immediatamente evidenti (sebbene apparentemente siano stabiliti in campi specifici). Non discuterei di xey, visto che le coordinate cartesiane sono applicabili a qualsiasi numero di campi e vengono insegnate a tutti nella scuola media e superiore.
KChaloux,

1
E xe y, sebbene comune, non portare aspetti impliciti importanti come dove l'origine.
Ross Patterson,

3
@RossPatterson: tuttavia, ci sono molti contesti in cui questo semplicemente non è importante. Ad esempio, considera un ciclo come for (x,y) in list_of_coordinates: print x,y: L'origine non è particolarmente importante quando si cerca di capire il codice.
Bryan Oakley,

16

Secondo "Clean Code":

I nomi delle variabili dovrebbero:

  • Sii intenzionale a rivelare
  • Evita la disinformazione
  • Fai distinzioni significative
  • Sii pronunciabile
  • Sii ricercabile

Le eccezioni sono il proverbiale i,j,k,m,nusato per i loop.

La variabile di cui ti lamenti, giustamente, ti lamenti di non fare nulla di quanto sopra. Quei nomi sono cattivi nomi.

Inoltre, poiché ogni metodo deve essere breve , l'utilizzo dei prefissi per indicare l'ambito o il tipo non è più in uso.

Questi nomi sono migliori:

radius
curvature
conicConstant
innerAperture
outerAperture
innerRadius
outerRadius

Un commentatore afferma che questo sarebbe troppo complesso con nomi di variabili lunghe:

inserisci qui la descrizione dell'immagine

I nomi di variabili brevi non lo rendono nemmeno semplice:

fnZR = (r^2/fnR(1+Math.sqrt((1+k) * (r^2/R^2)))) + a[1]*r^2 + a[1]*r^4 + a[1]*r^6 ...;

La risposta è nomi lunghi e risultati intermedi fino a quando non ottieni questo alla fine:

thisNiceThing =  ( thisOKThing / thisGreatThing ) + thisAwsomeThing;

26
Queste variabili sono probabilmente utilizzate nelle formule matematiche nel codice. Le formule matematiche sono molto più facili da leggere con nomi di variabili brevi. Uso i nomi di variabili lunghe nella maggior parte del mio codice, ma la matematica è migliore con i nomi di variabili brevi. Esempio a caso: considerare quanto tempo questo sarebbe con nomi di variabili lunghi.
MarkJ,

@MarkJ Hai ragione.
Tulains Córdova,

1
I risultati intermedi hanno l'ulteriore vantaggio di ridurre e isolare gli errori di programmazione. Il nostro cervello può elaborare solo così tante informazioni alla volta, ed è difficile individuare l'errore in qualcosa di similefnZR = (r^2/fnR(1+Math.sqrt((1+k)) * (r^2/R^2))) + a[1]*r^2 + a[1]*r^4 + a[1]*r^6 ...;
mancanza di palpebre

1
Non è così difficile se questo è il tuo pane e burro.
Radu,

1
Il punto non è scrivere una riga. Ma il problema è che se avete bisogno di cambiare qualcosa e utilizzare un'altra formula ora avete un problema in cui ci vuole molto tempo per capire che long_namel' Rnel libro di testo si riferisce a. Usa i risultati intermedi, ma mantieni i tuoi calcoli complessi il più vicino possibile al dominio problematico in modo da poterlo effettivamente gestire se devi aggiungere una funzione.
slebetman,

8

Esistono due buoni motivi per non rinominare le variabili nel codice legacy.

(1) a meno che non si stia utilizzando uno strumento di refactoring automatizzato, la possibilità di introdurre bug è elevata. Quindi, "se non è rotto, non aggiustarlo"

(2) farai il confronto tra le versioni attuali e le versioni precedenti, al fine di vedere cosa è cambiato, impossibile. Ciò renderà più difficile la futura manutenzione del codice.


7
Assolutamente corretto, ma il rischio di mancanza di comprensione è molto maggiore.
Ross Patterson,

2
Hai problemi molto più grandi se i tuoi strumenti non sono in grado di gestire problemi semplici come quelli che hai citato.
AndSoYouCode

Risposte (1) Ragionevole copertura automatizzata dei test e incapsulamento sano, (2) Competenza con controllo della versione.
Adamantish

5

C'è una buona ragione per nominare le variabili in questo modo o sono giustificato aggiornandole a nomi più descrittivi quando li incontro?

Il motivo per usare nomi più piccoli è se il programmatore originale li trova più facili da lavorare. Presumibilmente hanno il diritto di scoprire che è così e il diritto di non avere le stesse preferenze personali che hai. Personalmente, troverei ...

dDin better than dDinnerAperture
dDout better than dDouterAperture

... se li stessi usando in calcoli lunghi e complessi. Più piccola è l'espressione matematica, spesso è più facile vedere tutto in una volta. Anche se in tal caso, potrebbero essere migliori come dIn e dOut, quindi non c'era una D ripetitiva che potesse portare a un errore di battitura semplice.

D'altra parte, se trovi più difficile lavorare con te, poi buttati fuori e rinominalo nella loro forma più lunga. Soprattutto se sei responsabile di quel codice.


7
Almeno mi
libererò

4
Il leader dè ungherese? Ho pensato che fosse un calcolo come in dx^2/dx = 2x.
Shannon Severance,

7
Se lo vedessi dDinnerApertureda solo, lo leggerei come "Apertura della cena", e mi chiedo se è solo un modo divertente di dire "la tua bocca". Non sono mai stato un fan dello stile "maiuscola seguito da una minuscola). A volte molto confuso.
Darrel Hoffman,

2
+1 questa è la risposta. Le formule matematiche lunghe sono molto più facili da leggere con nomi di variabili brevi. Queste variabili sono probabilmente utilizzate nelle formule matematiche nel codice. Le formule matematiche sono molto più facili da leggere con nomi di variabili brevi. Uso i nomi di variabili lunghe nella maggior parte del mio codice, ma la matematica è migliore con i nomi di variabili brevi. Esempio a caso: considerare quanto tempo questo sarebbe con nomi di variabili lunghi.
MarkJ,

1
@ShannonSeverance Sono d'accordo con te. Proveniente da un background ingegneristico, d dovrebbe sicuramente essere riservato per il calcolo quando si usano nomi di variabili in senso matematico (come è spesso menzionato qui).
CodeMonkey

4

In generale, credo che la regola per questo, dovrebbe essere che puoi usare nomi di variabili estremamente brevi in ​​cui sai che le persone "esperte nell'arte" del tuo particolare codice capiranno immediatamente il riferimento di quel nome di variabile. (Hai sempre commenti ad eccezione di questo caso in ogni caso) e che l'uso localizzato delle variabili può essere facilmente individuato in base al contesto in cui vengono utilizzate.

Espandersi su questo, significa che non dovresti fare di tutto per offuscare i nomi delle tue variabili, ma puoi usare le abbreviazioni per i nomi delle tue variabili, dove sai che sono probabili solo le persone che capiscono il concetto alla base del tuo codice per leggerlo comunque.

Per usare un esempio del mondo reale, di recente, stavo creando una classe Javascript che avrebbe richiesto una latitudine e ti avrei detto la quantità di luce solare che ti aspetteresti in una determinata data.

Per creare questa lezione sulla Meridiana , ho fatto riferimento a forse mezza dozzina di risorse, l'Astronomia Almanacco e frammenti di altre lingue (PHP, Java, C ecc.).

In quasi tutti questi, hanno usato abbreviazioni identiche simili, che sulla sua faccia non significano nulla di assoluto.

K, T, EPS, deltaPsi, eot, LM,RA

Tuttavia, se hai conoscenza della fisica puoi capire cosa fossero. Non mi aspetto che nessun altro tocchi questo codice, quindi perché usare nomi variabili variabili?

julianTime, nutationOfEclipticalLongitudeExpressedInDegrees, equationOfTime, longitudeMean, rightAscension.

Inoltre, molte volte, quando i nomi delle variabili sono transitori, vale a dire, vengono utilizzati solo per allocare temporaneamente un valore, quindi spesso non ha senso utilizzare una versione dettagliata, specialmente quando il contesto della variabile spiega il suo scopo.


1

C'è assolutamente; spesso è sufficiente un breve nome di variabile.

Nel mio caso, sto effettuando la navigazione waypoint nella mia classe di robotica senior e programmiamo i nostri robot in KISS-C. Abbiamo bisogno di variabili per le coordinate correnti e di destinazione (x, y), distanze (x, y), intestazioni di corrente e di destinazione, nonché angoli di virata.

Soprattutto nel caso delle coordinate xey, un nome di variabile lungo è completamente inutile e nomi come xC (corrente x), yD (destinazione y) e pD (destinazione phi), sono sufficienti e sono i più facili da capire in questo caso.

Potresti sostenere che questi non sono "nomi di variabili descrittivi" come detterebbe il protocollo del programmatore, ma poiché i nomi si basano su un semplice codice (d = destinazione, c = corrente), un commento molto semplice all'inizio è tutta la descrizione richiedono.


0

C'è una buona ragione per nominare le variabili in questo modo o sono giustificato aggiornandole a nomi più descrittivi quando li incontro?

Di solito, algoritmi complessi sono implementati in matlab (o linguaggio simile). Quello che ho visto è che la gente ha appena assunto il nome della variabile. In questo modo, è semplice confrontare le implementazioni.

Tutte le altre risposte sono quasi corrette. Queste abbreviazioni si trovano in matematica e fisica, tranne che non iniziano con d(come nel tuo esempio). Le variabili che iniziano con d vengono generalmente denominate per rappresentare differenziazione .

Tutte le normali guide alla codifica dicono di non nominare le variabili con la prima lettera che rappresenta il tipo (come nel tuo caso), perché è così facile sfogliare il codice in tutti gli IDE moderni.


Bene, quell'elemento andava via indipendentemente da ciò che la gente finiva per dire. C'è una sorta di schizofrenia metà ungherese e metà non in corso che sto aggiornando mentre la trovo.
KChaloux,

0

Posso pensare a una ragione per cui i nomi delle variabili siano ragionevolmente brevi.

I nomi brevi sono facili da leggere usando un intervallo di occhi più breve, quindi un breve intervallo di attenzione.

Ad esempio, una volta che mi sono abituato al fatto che svdb significa "salva nel database", la velocità di scansione del codice sorgente migliora poiché devo solo scansionare rapidamente 4 caratteri invece di leggere SaveToDatabase (14 caratteri, le cose peggiorano per nomi di operazioni più complessi). Dico "scansionare" non "leggere", perché ciò richiede gran parte dell'analisi del codice sorgente.

Quando si esegue la scansione di grandi quantità di codice sorgente, ciò può fornire buoni guadagni in termini di prestazioni.

Inoltre, aiuta il programmatore pigro a digitare questi nomi brevi durante la scrittura del codice.

Naturalmente, tutti questi "shorthands" dovrebbero essere elencati in una posizione standard nel codice sorgente.


1
Non leggiamo le parole come un insieme di caratteri, le leggiamo come forme e risolviamo i dettagli in modo condizionale quando la comprensione a colpo d'occhio fallisce. La lunghezza che una parola deve impiegare più tempo a leggere è di gran lunga superiore a 4 caratteri e siamo in grado di elaborare mentalmente camelCase e altri mezzi per spezzare le parole con i nomi delle variabili come limiti di parole. Dubito che un test di lettura confermerebbe che nomi più brevi migliorano la velocità di comprensione della lettura; rimuovendo invece le parole riconoscibili, ci sarà una diminuzione della velocità fino a quando le nuove parole non saranno assimilate (come tu stesso fai notare).
ciglia

0

Per inquadrare ciò che @zxcdw ha detto in un modo leggermente diverso ed elaborarlo in termini di approccio:

Le funzioni dovrebbero essere pure , brevi e un perfetto incapsulamento di alcune funzionalità: la logica della scatola nera , indipendentemente dal fatto che sia rimasta intatta per 40 anni, continuerà a fare il lavoro per cui è stata progettata, perché la sua interfaccia (dentro e fuori) è sano, anche se non sai nulla dei suoi interni.

Questo è il tipo di codice che vuoi scrivere: questo è il codice che dura ed è semplice da portare.

Se necessario, comporre le funzioni da altre chiamate di funzione (inline) , per mantenere il codice a grana fine.

Ora, con un nome di funzione adeguatamente descrittivo (dettagliato se necessario!), Minimizziamo ogni possibilità di interpretazione errata di quei nomi di variabili abbreviati, poiché l'ambito è così piccolo.


-1

I nomi delle variabili dovrebbero essere il più descrittivi possibile per aiutare la leggibilità del programma. L'hai provato tu stesso: hai avuto molti problemi a identificare ciò che il programma ha fatto a causa della scarsa denominazione.

Non ci sono buoni motivi per non usare il nome descrittivo. Ti aiuterà e tutti gli altri che lavorano / lavoreranno al progetto. Bene, in realtà esiste un solo uso valido per i nomi brevi: contatori di loop.


6
Si noti che int dummy_variable_for_for_loops;è il più descrittivo possibile.
Kaz,

4
-1 perché questa risposta è confusa. Prima dice che non ci sono buone ragioni, poi finisce dicendo che in realtà ci sono. La risposta sarebbe migliore se fosse riformulata per non contraddire se stessa.
Bryan Oakley,

Lo cambierei per leggere "tanto descrittivo quanto necessario ". Se un nome breve trasmette lo scopo della variabile, allora è OK usare un nome breve .
Maximus Minimus,

-1

Sicuramente questo è a cosa // commenti servono?

Se i compiti hanno commenti descrittivi, ottieni il meglio da entrambi i mondi: una descrizione della variabile e le eventuali equazioni sono facilmente confrontabili con la loro controparte del libro di testo.


-1

Per le interfacce (ad es. Firme di metodi, firme di funzioni) tendo a risolverlo annotando le dichiarazioni dei parametri. Per C / C ++ questo decora il file .h e il codice dell'implementazione.

Faccio lo stesso per le dichiarazioni delle variabili in cui la conoscenza dell'uso della variabile non è ovvia nel contesto e nella denominazione. (Questo vale anche per le lingue che non hanno una digitazione forte.)

Ci sono molte cose che non vogliamo ostruire il nome della variabile. È l'angolo in radianti o gradi, esiste una certa tolleranza sulla precisione o sull'intervallo, ecc. Le informazioni possono fornire affermazioni preziose sulle caratteristiche che devono essere trattate correttamente.

Non sono religioso a riguardo. Sono semplicemente interessato alla chiarezza e ad assicurarmi che ora è quello che è la prossima volta che il mio io smemorato visita il codice. E chiunque mi guardi alle spalle ha ciò che deve sapere per vedere dove qualcosa è spento, ciò che è essenziale (l'ultimo critico per una corretta manutenzione).


-1

Esiste una scusa per nomi di variabili eccessivamente brevi?

Primo: la denominazione di una variabile per l'energia e durante il calcolo di formule come E = MC2 NON è una denominazione eccessivamente breve. L'uso dei simboli come argomento per i nomi brevi non è valido

Questa domanda è stata piuttosto interessante per me, e posso solo pensare a una scusa e che è denaro.

Supponiamo ad esempio che stai collegando javascript a un client che sa che il file deve essere scaricato più volte al secondo. Sarebbe più economico e migliorerebbe l'esperienza degli utenti se il file (in numero di byte) fosse il più piccolo possibile.

(Solo per mantenere l'esempio "realistico", non ti è stato permesso di usare uno strumento di minificazione, perché? Problemi di sicurezza, nessuno strumento esterno ha permesso di toccare la base di codice.)


1
Il tuo esempio non è ancora molto realistico.
Radu,

-1

Noto che le altre risposte non menzionano l'uso della notazione ungherese. Questo è ortogonale al lungo dibattito, ma è rilevante per gli schemi di denominazione in generale.

double dR, dCV, dK, dDin, dDout, dRin, dRout

La "d" all'inizio di tutte queste variabili intende indicare che sono doppie; ma la lingua lo impone comunque. Nonostante la tresidezza di questi nomi, sono ridondanti fino al 50% !

Se utilizzeremo una convenzione di denominazione per ridurre gli errori, è molto meglio codificare le informazioni che non vengono controllate dalla lingua. Ad esempio, nessuna lingua si lamenterà dK + dRnel codice sopra, anche se non ha senso aggiungere un numero senza dimensioni a una lunghezza.

Un buon modo per prevenire tali errori è usare tipi più forti; tuttavia, se utilizzeremo i doppi, uno schema di denominazione più appropriato potrebbe essere:

// Dimensions:
// l  = length
// rl = reciprocal length
double lR, rlCV, K, lDin, lDout, lRin, lRout

La lingua ci consentirà comunque di scrivere K + lR, ma ora i nomi ci danno un suggerimento che ciò potrebbe non essere corretto.

Questa è la differenza tra sistemi ungheresi (generalmente non validi) e app ungheresi (possibilmente buoni)

http://en.wikipedia.org/wiki/Hungarian_notation


1
In realtà, C ++ può lamentarsi K + lR se dichiari correttamente le tue unità. Con le unità SI può eseguire controlli di dimensionalità e conversione delle unità. L'aggiunta non 3_feet + 2_meterdovrebbe essere un problema, mentre 2_meter+1_seconddovrebbe essere un errore di compilazione.
Salteri,

@MSalters È abbastanza bello; un approccio modello / macro non mi era venuto in mente. Tuttavia, in una domanda "indipendente dalla lingua" come questa raggrupperei tutti i controlli delle unità in fase di compilazione sotto l'ombrello "tipi più forti", indipendentemente dal fatto che la lingua li chiami "tipi" o meno;)
Warbo,

Modello, necessariamente. Non è possibile eseguire il calcolo del tipo necessario nelle macro.
Salterio,

-2

L' unico caso in cui nomi variabili variabili illegalmente accettabili sono accettabili nella moderna ingegneria del software è quando esistono in uno script e il throughput di quello script (su una rete in generale) è importante. Anche allora, mantieni lo script con nomi lunghi nel controllo del codice sorgente e minimizza lo script in produzione.


9
Che dire quando si eseguono operazioni matematiche in cui i termini sono considerati conoscenza comune nel dominio? Esempio: usare M invece di "massa" in e = mc ^ 2
Andy Hunt,

2
@andyBursh - Starei attento lì. I programmatori non sono spesso esperti (o nemmeno competenti) nel loro dominio problematico. Detto questo, questo genere di cose può essere a posto, specialmente se c'è il link di commento appropriato alla formula in questione; Mi ero dimenticato di questo scenario.
Telastyn,

8
@Telastyn - Se supponi che il programmatore non sia un esperto, tuttavia, ciò porta spesso a prendere abbreviazioni che hanno un significato molto ben definito e a trasformarle in nomi più lunghi almeno un po 'ambigui (cioè qualcuno decide di nominare una variabile locale radiusquando immagazzina il raggio interno non capendo che è molto più ambiguo di Rin). E quindi lo sviluppatore non esperto deve tradurre tra la sua nomenclatura unica e la nomenclatura che l'azienda capisce ogni volta che c'è una discussione che coinvolge equazioni.
Grotta di Giustino,

2
Che dire di "i" per un contatore di loop? O "x" e "y" quando si ha a che fare con una coordinata? O una variabile il cui ambito è solo due righe di codice?
Bryan Oakley,

4
Non sono d'accordo con questa risposta. Un programmatore che lavora su un programma contenente espressioni matematiche complesse dovrebbe essere in grado di leggere almeno le formule nelle specifiche, altrimenti non sono competenti. Non è una conoscenza del dominio problematica, è un'abilità essenziale - alcune competenze matematiche di base prima di lavorare su un programma matematico. Se il programmatore non ha accesso alle formule delle specifiche, questo è un altro problema e non può essere risolto solo dai commenti.
MarkJ,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.