Qual è il motivo dell'uso di lettere minuscole per la prima parola in una variabile locale (ad es. employeeCount, firstName)

Questa convenzione di denominazione viene spesso utilizzata quando le persone vogliono essere in grado di assegnare a una variabile lo stesso nome del tipo. Ad esempio:

Employee employee;

Alcune lingue applicano anche questa maiuscola. Questo impedisce di usare nomi di variabili fastidiosi come MyEmployee , CurrentEmployee , EmployeeVar , ecc. Puoi sempre dire se qualcosa è un tipo o una variabile, solo dalla lettera maiuscola. Ciò impedisce la confusione in situazioni come:

employee.function(); // instance method
Employee.function(); // static method

Inoltre, in inglese, i nomi non sono generalmente in maiuscolo, quindi non puoi davvero affermare che la tua maiuscola è "corretta".

Quindi cosa ha a che fare con la tua situazione? Ovviamente non hai problemi a leggere il tuo codice, ma mantenendo le cose il più possibile coerenti, riduci il carico di lavoro mentale di chiunque altro abbia bisogno di leggere il tuo codice. Nella codifica come nella scrittura, regoli il tuo stile in modo che corrisponda ai lettori.

Non ce n'è. È quello che fa la maggior parte delle persone, quindi è diventato lo standard perché è quello che fanno tutti. Un sacco di letteratura segue questa convenzione, quindi la gente ha preso l'abitudine.

La convenzione non è importante quanto la coerenza attraverso il codice. Finché tutto è chiamato in modo coerente in modo che io possa capire quali cose sono dal guardarle, non importa se la prima lettera sia maiuscola o meno.

Trovo sconcertante imbattersi in codice scritto a tuo modo e direi che non mi piace. Ma questa è una questione di stile.

Ora, se lo stai facendo sul posto di lavoro, sarebbe meglio codificare lo stile della squadra in modo che il codice rimanga coerente ovunque. Piuttosto che avere il tuo codice essere diverso da tutti gli altri.

link

1. Perché esiste lo standard?

Dopo tutto, non sarebbe meglio lasciare che tutti scrivessero il codice in base alle preferenze personali e smettere di parlare di quale standard è meglio?

Il fatto è che quando si è abituati a uno stile, è più difficile leggere il codice che utilizza uno stile diverso. Il tuo cervello passa più tempo a cercare di capire la convenzione (se ce n'è), invece di capire cosa fa il codice.

Che cosa è più leggibile tra questi due pezzi di codice?

public void comp_metrics ()
{
  int Count;
  List<snapshot> measurements=fromMemoryStorage();
  if (_liveMeasurements.enabled)
    measurements = GrabSnapshots(20, _cache);
    if( !measurements.Any() ) {
        this.Report(LogMessage.Measurements_Are_Empty); return;
    }

    Count = measurements.Count ();

    this.Chart.initialize(( Count + 1 )*2);

    foreach(snapshot S in measurements) {
      this.Chart.append_Snapshot ( S );
    }
}

o

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var snapshots = this.liveMeasurements.isEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var count = measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

Entrambi i pezzi di codice vengono eseguiti allo stesso modo. L'unica differenza è che nel primo caso, ogni sviluppatore che ha lavorato al progetto ha usato il proprio stile. Ciò ha reso il codice incoerente, illeggibile e pericoloso. Il fatto che i membri del team non sono stati in grado di concordare sulla dimensione del rientro, insieme al fatto che uno di loro si rifiutava di usare parentesi graffe dopo che ogni if rendeva il codice estremamente soggetto a errori: guardandolo, potremmo credere che il secondo if viene eseguito solo quando il primo if è vero, il che non è il caso.

Nel secondo caso, tutti gli sviluppatori hanno seguito lo stesso standard. Alcuni di loro erano forse infelici, perché preferivano due indentazioni di spazi o perché erano abituati a metodi che iniziano con una piccola lettera. Il fatto è che il codice è ancora molto più leggibile in questo modo, e lo sarebbe ancora se stessero usando uno standard diverso.

Avendo uno standard rigoroso e uniforme, rende il codice più facile da leggere.

2. Perché il loro standard è migliore di quello che io e il mio ho inventato adesso?

Se uno standard viene utilizzato da centinaia di migliaia di sviluppatori in tutto il mondo, limitati a seguirlo. Non inventare il tuo: anche se è meglio, è più facile per te migrare allo standard globale piuttosto che a quelle centinaia di migliaia di sviluppatori per iniziare a usare il tuo.

Esempio: nella mia azienda, ho una convenzione specifica per nominare chiavi e indici primari e stranieri nel database. Sembrano questi nomi:

• [FK for Application: CreatedByApplicationId] ,
• [IX for SessionIPAddress: SessionId] o
• [PK for RoleOfPassword: RoleId, PasswordId] .

Personalmente, trovo questa convenzione eccellente ed estremamente chiara. Per me. Ma totalmente fa schifo. Fa schifo, perché è mio, e perché nessuno dei migliaia di amministratori di database lo ha mai usato. Questo significa che:

• Quando assumerò un DBA, sarà costretto ad imparare la nuova convenzione, invece di iniziare il suo lavoro in questo momento,

• Non posso condividere pezzi di codice su Internet così com'è: quei nomi dall'aspetto strano disturberanno le persone che leggeranno il mio codice,

• Se prendo il codice dall'esterno per usarlo nel mio, sarei costretto a modificare i nomi per renderlo uniforme,

• Se un giorno deciderò di utilizzare uno standard ben noto, sarò costretto a modificare ogni delle centinaia di nomi.

3. Quindi, per quanto riguarda la maiuscola?

Le proprietà hanno un ambito o una visibilità maggiore rispetto ai campi o alle variabili locali. Fare le proprietà inizia con una lettera maiuscola, e campi e variabili - con uno piccolo va in questa direzione.

Se consideri C #, questa logica è abbastanza coerente.

Se consideri Java, i metodi iniziano con lettere minuscole, che non seguono la logica.

Quindi no, non esiste una prova definitiva che questa convenzione sia migliore della tua. È solo che quello è usato globalmente, e il tuo no. Nessuno è migliore .

In JavaScript, le funzioni iniziano con una lettera minuscola, a meno che non richiedano un new prima di esse. Non sarebbe meglio il contrario? Può essere. Il fatto è che per anni gli sviluppatori di JavaScript hanno usato questo standard, e non il contrario. Riscrivi ogni libro e costringi ogni sviluppatore a cambiare lo stile ora sarebbe un po 'complicato.

Tecnicamente, non importa (o almeno, nella maggior parte delle lingue non lo è).

Tuttavia, la maggior parte delle comunità di programmazione (siano esse comunità mondiali che si sono formate attorno a una particolare lingua, sottogruppi di tali comunità, gruppi che si sono formati attorno a una libreria o toolkit popolare, o solo a singoli gruppi) si sono sviluppati standard di codifica. I dettagli esatti sono relativamente poco importanti (anche se in molti casi è possibile fare un buon argomento), ciò che è importante è che vi atteniate a loro.

Non perché siano i migliori, ma perché sono quello che usano gli altri; se ti attieni allo standard, il tuo codice sarà coerente con la maggior parte degli altri codici che alla fine finirai usando - librerie, codice di compagni di squadra, built-in di linguaggio. La denominazione coerente è un'arma potente per la produttività, perché significa che quando indovini il nome di qualcosa, di solito indovinerai correttamente. file.SaveTo() , File.saveTo() , file.save_to() , FILE.save_to() ? La convenzione di denominazione ti dirà.

Portare le tue preferenze personali in ogni lingua che incontri è particolarmente rischioso, perché prima di tutto ogni lingua ha una propria cultura e le convenzioni di denominazione sono spesso incompatibili; e in secondo luogo, ci sono molte sottili differenze tra le lingue per quanto riguarda la denominazione.

Un solo esempio: in C #, tipi e variabili vivono in spazi dei nomi separati; il compilatore è abbastanza intelligente da sapere la differenza. In C, tuttavia, entrambi i tipi di nomi condividono uno spazio dei nomi, quindi non è possibile avere un tipo e una variabile con lo stesso nome all'interno dello stesso ambito. Per questo motivo, C ha bisogno di una convenzione di denominazione che distingua i tipi dalle variabili, mentre C # non lo fa.

Sono sorpreso che nessun altro abbia detto questo, ma penso che la differenza di capitalizzazione sia straordinariamente utile per una ragione: è bello e comodo essere in grado di sapere se una variabile ha un solo ambito locale o meno. Se la variabile è locale, non mi preoccupo tanto degli effetti collaterali della modifica, come ad esempio il refactoring del nome. Quindi mi piace una convenzione che distingua i membri della classe rispetto alle variabili di classe private rispetto alle variabili locali.

Con Intellisense moderna, questo conta sempre meno, ma mi dà ancora alcuni punti di riferimento mentre leggo il codice per sapere dove cercare la definizione.

E un bel po 'di questo potrebbe essere passato dal mio stile peggiore anni fa, quando i metodi non erano così adatti a stare su uno schermo.

Questo sembra più una questione di convenzioni piuttosto che la tua convenzione specifica.

Per ogni convention che rompi, stai solo aggiungendo più lavoro per tutti gli altri. Forse in un mondo perfetto, l'intera azienda lavora su un singolo prodotto per tutta la vita ... tuttavia, in realtà, questo non è vero. Le persone saltano tra i progetti, a volte tra società o anche per divertimento. Più il codice è casuale, più difficile e costoso è lavorare. In quanto imprenditore o stakeholder, non vorrei assumere sviluppatori che pensano egoisticamente piuttosto che per il bene del progetto.

Questo si riduce alla professionalità: a volte abbiamo bisogno di mettere da parte i nostri stili personali e andare con quello che è più efficiente per l'adozione di massa. Ciò incoraggia la collaborazione e rimuove le barriere estranee che in primo luogo non dovrebbero esserci.

Per quanto riguarda la tua convenzione attuale, CapitalCamelCase è solitamente riservato ai nomi di classe (o in Javascript, costruttori). Se vedo una variabile in maiuscolo, è necessario che un'ipotesi calcolata abbia bisogno di istanziarla per usarla. Se questo è sbagliato, sarò incazzato perché il codice non sta seguendo gli standard della comunità. Anche con la maggior parte delle altre lingue, tutti gli altri che la guardano per la prima volta vengono immediatamente ingannati. Voglio che il codice sia ovvio, non fuorviante.

"perché il caso corretto completo dovrebbe essere riservato per le proprietà e i metodi void. La variabile locale ei metodi che restituiscono un valore dovrebbero avere la prima parola in minuscolo" e perché è una convenzione standard.

Al momento altri programmatori stanno cercando il codice e pensano che questa sia una proprietà ed è davvero una variabile locale, rendendo più difficile il loro lavoro.

Come altri hanno detto senza una vera ragione, tranne che per ottenere una convenzione di denominazione. Se riesci a portare tutta la tua squadra sulla stessa pagina, puoi probabilmente risparmiare tempo. Per esempio, personalmente ho iniziato una cosa sugli standard di codifica che ci siamo occupati di questo e abbiamo usato camelCase per tutte le varial private e le cose passate da Val, mentre abbiamo usato PascalCase per le cose che sono pubbliche così come le cose passate da Ref.

Le linee diventano un po 'sfocate quando si tratta di cose come protetto o Fuori o qualcosa del genere.

La lingua (con il suo aspetto formale e convenzionale) è importante per organizzare i tuoi pensieri, ha potere sui tuoi modi di pensare. Quindi è solo un dolore passare da uno stile all'altro.

I simboli minuscoli e maiuscoli hanno grandi differenze semantiche in Haskell, anche loro differiscono leggermente in Scala e li ho usati entrambi. Gli altri linguaggi che uso non fanno differenza tra questi due tipi di identificatori, ma mantenere i pensieri nel modo in cui Haskell percepisce gli identificatori è molto più facile per me che frammentare la mia mente per lingue diverse.

Per me si tratta di aspettative.

Quando leggo la maggior parte del codice, mi aspetto che tutto ciò che inizia con lowerCase sia una variabile locale o una funzione (in C # sarebbe solo una variabile). Se vedo una variabile locale in ProperCase , probabilmente inciampo e mi confondo per un po ', pensando che sia un nome di classe o una proprietà o qualcos'altro. Ciò mi indurrebbe a rileggere il codice e mi infastidirebbe.

È probabile ciò che sta accadendo nel tuo caso.

Inoltre, è comodo essere in grado di dire quale ruolo una variabile gioca solo guardando la prima lettera, ed evita gli scontri tra un nome di istanza e un nome di classe.

Sono d'accordo con l'OP qui. CamelCase sembra solo sbagliato. Sono anche d'accordo con il fatto che quello è lo standard e dobbiamo attenerci allo stesso standard o a che punto è avere uno standard. Ha anche senso che PascalCaps sia usato per i metodi etc e camelCase per le proprie variabili ecc. Come un modo per differenziare quando non si utilizza un IDE che colora i metodi per te.

Per aggirarlo, prefisso sempre i nomi dei miei oggetti con il tipo di oggetto che è. Quindi se si tratta di una variabile stringa, chiamo strMyVariable. Se si tratta di una sorta di oggetto, lo chiamo objMyObject, ecc. In questo modo si inizia con i maiuscoletti secondo lo standard e sembra giusto.

Per le variabili locali è necessario utilizzare lettere minuscole per semplificare la digitazione (tasto velocità / nessun turno). La maiuscola viene utilizzata per facilitare la leggibilità separando le parole all'interno di un nome. Il codice con nomi di variabili locali di una sola parola (che dovrebbero essere comuni) sono veloci e facili da digitare. L'uso del maiuscolo per ogni nuova parola nel nome è anche più veloce (e meno spazio) rispetto all'utilizzo di caratteri di sottolineatura che aggiungono un altro carattere - questo è anche noto come caso cammello.