Come abbreviare i nomi delle variabili [chiuso]

Lo standard che utilizzo non deve abbreviare i nomi delle variabili a meno che l'abbreviazione sia più leggibile della versione completa ( i per gli indici di iterazione, ad esempio). Denominiamo le cose in modo che possiamo comunicare. I nomi di variabili abbreviati in genere riducono la loro capacità di comunicare.

Non sono un programmatore C #, quindi non posso darti molti consigli sulle convenzioni C #. Ma ho qualche idea sulle abbreviazioni.

Quando sono diventato più grande e più esperto, mi sono ritrovato ad abbreviare sempre di più. Devo ammettere che non ero un buon dattilografo quando ho iniziato a programmare. Da allora sono migliorato in questo modo;). Abbrevierò liberamente le parole per variabili che hanno uno scopo molto limitato, così da poter vedere la loro intera vita su uno schermo. Ma a parte questo preferisco non farlo se posso evitarlo - non abbreviamo mai per salvare la digitazione.

Tento comunque di mantenere le mie battute sotto gli 80 caratteri. Non sono sicuro che questo abbia senso in questi giorni, ma è una vecchia abitudine. Quindi abbrevierò se un nome di variabile sarà altrimenti molto lungo. Ma prima di farlo cercherò di trovare un nome più succinto che sia ugualmente chiaro - tutto il resto uguale è più breve è migliore (parlando della forma espansa.)

Dove si abbrevia è molto importante, penso, che si abbrevia sempre nello stesso modo in un determinato codebase e attraverso codebase correlati. È probabile che il primo istinto sia quello da seguire, poiché sarà più semplice da ricordare, ma può valere la pena di verificare con altre persone sullo stesso progetto. In questi giorni lavoro principalmente con un altro programmatore, in un ufficio aperto pieno di non programmatori. Pensano che siamo pazzi, perché spesso abbiamo discussioni dettagliate su cose come come abbreviare in modo coerente nomi di variabili correlati, o coerentemente ordinare i parametri nelle chiamate di funzione, ecc. Ma le questioni di denominazione, anche per due persone. Nelle squadre più grandi diventa ancora più importante. Una cosa di cui sono piuttosto religioso è la correzione delle incoerenze in cose del genere non appena le vedo.

EDIT: alcune abbreviazioni sono buone, penso. Nel mio attuale lavoro molto del codice che scrivo ha a che fare con la valutazione di spline e altre funzioni parametriche, ad alcuni valori di parametro. Il nostro codebase è in realtà incoerente in questo senso. So che sei usato in alcuni posti e param (una stessa abbreviazione) è usato in altri. U è un'abbreviazione generalmente comprensibile per il parametro in questo dominio quindi penso che dovremmo farlo e renderlo coerente. Sarei perfetto con qualsiasi di u, param o parametro. Li usiamo così tanto che è improbabile che ci sia confusione, a patto che usiamo solo uno . Ma preferirei te.

È peggio di quello- abbiamo effettivamente diversi tipi di parametri. E abbiamo più di un nome per alcuni di loro - uggh.

Il motivo per cui è diventato inconsistente è il libro di testo. Si è scoperto che dovevamo mappare tra sei spazi parametrici - le ragioni sono complicate, ma fondamentalmente dovevamo avere parametri che corrispondessero allo spazio dei parametri, spazio dei parametri normalizzato, spazio della lunghezza dell'arco, spazio normalizzato della lunghezza dell'arco, spazio a tratti e normalizzato spazio a tratti. Non ci siamo resi conto, all'inizio, che avremmo dovuto mappare avanti e indietro tra tutti questi spazi. E non eravamo coerenti nel modo in cui abbiamo chiamato i parametri che descrivono i punti in quegli spazi.

Questo succede a volte- la tua app cresce e tu fai alcune cose incoerenti mentre lo fai crescere. L'importante è che tu riconosca di essere diventato disordinato ed entrare e sistemarlo prima che il disordine infetti tutto il resto e finisci con un cumulo di macerie.

Il vry rsn w dn't bbrvt s mk sr th cd s rdbl nd mntnbl per esempio.

int accountBalanceInSavings

--> could be abbreviated to

int accBalInSaving

Nota che due delle quattro parole sono a corto (account- > acc e Balance- > Bal), ma le altre due non lo sono. Quale regola viene applicata qui - Abbraccia le prime 2 parole, non è "parole su 6 lettere", perché 2 7 lettere erano e una no.

Quindi potrebbe / dovrebbe essere 'accBalInSav', yuk yuk yuk .......

La mia esperienza come programmatore diventa più vecchia e più saggia, si abbrevia sempre meno. Alla mia età, probabilmente stiamo cercando di compensare i peccati della nostra gioventù anche se .....

Ricorda che il codice viene scritto una volta (ok, molti altri ancora una volta) e letto migliaia di volte.

Non credo che esistano regole ufficiali o comuni per le abbreviazioni. Di solito un sistema di abbreviazioni è sviluppato da ogni individuo e all'interno di ogni singolo progetto. Ci possono essere alcune regole per la politica di stile del codice sorgente di una società, ma anche quella varierà sulla base dell'azienda.

Nota a margine, perché abbreviate? Ciò comporterà solo la comprensione di cosa significano le abbreviazioni. Utilizza nomi completi e descrittivi per le variabili. Ciò porterà al codice di autocertificazione.

C'è una domanda simile sui singoli nomi char, Utilizzo di caratteri singoli per nomi di variabili in loop / eccezioni .

La mia risposta allora come adesso è di tenerli corti laddove l'ambito è piccolo. Ad esempio, un parametro di una funzione breve è più leggibile se è breve e occupa meno spazio. Una variabile di classe dovrebbe essere molto descrittiva.

Il classico libro di Steve McConnell Il codice completo è ottimo per cose come questa.

In caso di dubbio, spelling fuori

Il punto di un nome di variabile è tale che il significato del codice è più chiaro. A meno che l'abbreviazione sia molto ovvia, allora puoi anche usare il più piccolo possibile. Nomi di variabili e nomi di funzioni sono in genere gli unici bit del linguaggio umano nel codice e quindi fungono entrambi da "punti di riferimento" per l'occhio umano per trovare parti rilevanti del codice (o, in una base di codice di grandi dimensioni, strumenti come grep o ack ) e anche come indizi per la comprensione.

Quando la prossima persona verrà a leggere il tuo codice, ti ringrazieranno per questo. Quella persona potrebbe benissimo essere tra un anno. Ho un sacco di codice che rimpiango di abbreviare, quindi oggigiorno cerco di evitarlo.

È ok abbreviare quando ...

... Quando la forma abbreviata viene utilizzata in inglese parlato o scritto da più di solo le persone che lavorano sul tuo progetto (molti dizionari forniscono questo tipo di informazioni accanto al termine che definiscono).

var extensible_markup_language_element; // don't do this
var xml_element; // better
var element; // possible if the name of the function or the documentation make it clear you're dealing with XML and not the periodic table
docs.toString(); // most people capable of reading code know docs == documentation

... Quando l'abbreviazione si riferisce in modo non ambiguo a un singolo concetto e sarebbe immediatamente riconosciuto da qualcuno che non ha familiarità con il codice base. Anche allora un commento o un pezzo di documentazione aiuta.

var auth = user.auth;
if (auth) // If the user is authenticated?
          // If the user is authorised to do something?
          // If the authentication function exists for that user group?
          // If some setting called auth is turned on for that user?
          // If the user is the author of the document in question?
          // If the user has some authority?

var attrNames = retrieveAttrs();
if (attrNames)  // hm, attrNames sounds like an array of strings - which will be boolean true even if empty - this if looks like a bug!

const MDF // author is writing an iOS app for ordering hand-carved artisanal fibreboard so anyone familiar with the problem domain knows this has plainly nothing to do with Microsoft Database Files. Though maybe the first time it comes up in the code the author should perhaps still put its full name

... Quando il nome della variabile esiste solo in un singolo ambito o in una piccola funzione e non ci si aspetta che l'utente tragga significato dal nome, utilizzare un singolo carattere. In questi casi, i e j sono comuni.

foreach $i (1..10) { say $announcement->[$i] }

... Quando si scrive un'interfaccia (cioè non un nome di variabile, quindi al di fuori dell'ambito della domanda, menzionato solo perché i nomi e le interfacce delle variabili che li impostano spesso usano lo stesso vocabolario) nel qual caso possono essere applicate altre regole, per esempio:

some_command --transaction-message "Done" # a bit wordy - keep, but ALSO allow for convenience:
some_command --msg "Done" # might be useful
some_command -m "Done"    # if you can spare -m

... Quando il codice base ha bisogno di riferirsi allo stesso concetto più volte nello stesso progetto e quando l'abbreviazione può essere definita in una guida di stile per quel progetto, e quando non è ambigua. Se il tuo progetto non è abbastanza grande per una guida di stile, non è abbastanza grande perché valga la pena.

Non fornirò un esempio di codice a questo perché per definizione funziona solo in un progetto di grandi dimensioni, ma vedi anche il prossimo elemento:

... Quando si lavora su un progetto stabilito che ha avuto più contributori e una guida di stile che impone abbreviazioni. In tal caso, abbrevia solo come per la guida di stile, ma cerca i problemi e preparati ad annotare con commenti (come "questo è un elenco di nomi di attributi come stringhe").

Types should end in “_t” ; Raw struct definitions in “_struct”

- https://metacpan.org/source/SHLOMIF/XML-LibXML-2.0117/HACKING.txt

Un ultimo pensiero: se hai ancora nomi di variabili inaccettabilmente lunghi (ad esempio composti da quattro o più unità semantiche come totalAfterTaxInLocalCurrency), potrebbe essere un sintomo che il tuo codice sta cercando di fare troppo in un singolo ambito e le sue funzioni necessitano essere refactored out o le tue variabili potrebbero essere gestite più logicamente in un singolo oggetto.

Il motivo per cui abbreviamo le variabili è di smettere di digitare variabili di grandi dimensioni, ma allo stesso tempo la variabile abbreviata dovrebbe essere abbastanza esplicita da poter capire cosa contiene invece di tornare a dove è stata dichiarata o istanziata per prima. Quindi per esempio:

int accountBalanceInSavings

- > potrebbe essere abbreviato in

int accBalInSaving

--- > ma abbreviandolo a

int accBal

Non sarebbe sicuramente una buona opzione in quanto uno non sarebbe in grado di capire cosa tiene la variabile solo guardandola.

Non dovresti abbreviare le cose per il bene abbreviato, dovresti farlo per la tua / altrui convenienza, ma se vuoi allora una regola generale che ho per l'abbreviazione è se una parola è più di quattro o cinque lettere lunghe poi accorgerò le prime tre lettere significative di quella parola, ad esempio:

int damagePerSecond;

potrebbe essere abbreviato in

int dmgPerSec;

o se lo vuoi il più breve possibile,

int dps;