Qual è la ragione per usare la minuscola per la prima parola in una variabile locale (es. EmployeeCount, firstName)

Prendo molte critiche da altri programmatori a causa del mio uso di un involucro completo per tutte le mie variabili. Ad esempio, il tuo programmatore tipico utilizzerà employeeCountper un nome variabile, ma io uso EmployeeCount. Uso il case completo per tutto , sia esso un metodo vuoto, un metodo di ritorno, una variabile, una proprietà o una costante. Seguo persino questa convenzione in Javascript. Quest'ultimo fa davvero frusciare le menzogne ​​della gente.

Il motivo tipico dato per cui non dovrei seguire questa convenzione di involucro "non standard" è perché il caso completo dovrebbe essere riservato per proprietà e metodi vuoti. La variabile locale e i metodi che restituiscono un valore dovrebbero avere la prima parola in minuscolo int employeeCount = getEmployeeCount().

Tuttavia, non capisco perché.

Quando metto in dubbio questo, sembra che ottenga una risposta arbitraria di quello standard . Qualunque sia la risposta, di solito si riduce sempre a Questo è il modo in cui è e non lo metto in discussione. Lo seguo e basta. . Le risposte arbitrarie non sono mai abbastanza buone per me.

Fin dai miei primi giorni di programmazione di macro di Excel 97 con l'IDE di Office, non ho mai avuto bisogno di una convenzione di casing per dirmi se qualcosa è una variabile o proprietà locale. Questo perché ho sempre usato una convenzione di denominazione molto intuitiva. Ad esempio, GetNuggetCount()suggerisce chiaramente un metodo che va da qualche parte e ottiene un conteggio di tutte le pepite. SetNuggetCount(x)suggerisce di assegnare un nuovo valore al conteggio dei nugget. NuggetCounttutto da solo suggerisce una proprietà o una variabile locale che contiene semplicemente un valore. A quest'ultimo si può essere tentati di dire: "Ah ah! Questa è la domanda. Proprietà o variabile? CHE COS'È?" A quello, risponderei con "Importa davvero?"

Quindi, ecco il tl; dr ;: quali sono le ragioni oggettive, logiche, non arbitrarie per usare le lettere minuscole per la prima parola nella variabile o nel metodo return?

Modifica: per MainMa

Sostituisci questo codice con il primo esempio di codice nella tua risposta e vedi quanto bene sostiene il tuo argomento:

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 MeasurementCount = Measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

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

Tale convenzione di denominazione viene spesso utilizzata quando le persone vogliono poter assegnare a una variabile lo stesso nome del suo tipo. Per esempio:

Employee employee;

Alcune lingue applicano persino tale capitalizzazione. Questo evita di dover utilizzare nomi di variabili come fastidiosi MyEmployee, CurrentEmployee, EmployeeVar, ecc Si può sempre dire se qualcosa è un tipo o di una variabile, solo dalla capitalizzazione. Ciò impedisce la confusione in situazioni come:

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

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

Cosa c'entra questo con la tua situazione? Ovviamente non hai problemi a leggere il tuo codice, ma mantenendo le cose il più coerenti possibile, riduci il carico di lavoro mentale di chiunque abbia bisogno di leggere il tuo codice. Nella codifica come nella scrittura, modifichi il tuo stile per adattarlo ai lettori.

Non ce n'è. È quello che fanno la maggior parte delle persone, quindi è diventato lo standard perché è quello che fanno tutti. Molta letteratura segue questa convenzione, quindi le persone hanno preso l'abitudine.

La convenzione non è importante quanto la coerenza nel codice. Fintanto che tutto è nominato in modo coerente in modo che io possa dire quali sono le cose osservandole, non importa se la prima lettera sia maiuscola o meno.

Lo troverei straziante imbattersi in un codice scritto a modo tuo e direi che non mi piace. Ma questa è una questione di stile.

Ora, se lo stai facendo sul posto di lavoro, sarebbe meglio codificare nello stile del team in modo che il codice rimanga coerente ovunque. Piuttosto che avere il tuo codice essere diverso da quello che tutti pensano.

http://thecodelesscode.com/case/94

1. Perché esiste lo standard?

Dopotutto, non sarebbe meglio permettere a tutti di scrivere il codice in base alle preferenze personali e smettere di parlare di quale standard è meglio?

Il fatto è che quando sei abituato 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'è una), invece di capire cosa fa il codice.

Cosa c'è di più leggibile tra quei 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 in modo simile. 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 fossero in grado di concordare sulla dimensione del rientro, unito al fatto che uno di loro si stava rifiutando di utilizzare parentesi graffe dopo ogni ifreso rendeva il codice estremamente soggetto a errori: osservandolo, potremmo credere che il secondo ifsia 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 il rientro di due spazi o perché erano usati per 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 ho inventato in questo momento?

Se uno standard viene utilizzato da centinaia di migliaia di sviluppatori in tutto il mondo, basta attenersi ad esso. 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 ed esterni nel database. Quei nomi sembrano:

• [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 fa davvero schifo. Fa schifo, perché è mio e perché nessuno dei migliaia di amministratori di database non l'ha mai usato. Ciò significa che:

• Quando assumerò un DBA, sarà costretto a imparare la nuova convention, invece di iniziare subito il suo lavoro,

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

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

• Se un giorno decido di utilizzare uno standard ben noto, sarò costretto ad andare a modificare ognuna delle poche centinaia di nomi.

3. Quindi, per quanto riguarda la capitalizzazione?

Le proprietà hanno un ambito o una visibilità maggiore rispetto ai campi o alle variabili locali. Fare in modo che le proprietà inizino con una lettera maiuscola e campi e variabili - con una piccola va in questa direzione.

Se si considera C #, questa logica è abbastanza coerente.

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

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

In JavaScript, le funzioni iniziano con una piccola lettera, a meno che non richiedano una newprima. Non sarebbe meglio nell'altro modo? Può essere. Il fatto è che per anni gli sviluppatori JavaScript hanno usato questo standard e non il contrario. Riscrivere ogni libro e forzare ogni sviluppatore a cambiare lo stile ora sarebbe leggermente complicato.

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

Tuttavia, la maggior parte delle comunità di programmazione (che si tratti di comunità di tutto il mondo che si sono formate attorno a un particolare linguaggio, sottogruppi di tali comunità, gruppi che si sono formati attorno ad alcune librerie o toolkit popolari o solo singoli team) hanno sviluppato standard di codifica stabiliti. I dettagli esatti sono relativamente poco importanti (anche se in molti casi, un buon argomento può essere fatto per loro), ciò che è importante è che si bastone a loro.

Non perché sono i migliori, ma perché sono ciò che usano tutti gli altri; se ti attieni allo standard, il tuo codice sarà coerente con la maggior parte dell'altro codice che finirai per usare - librerie, codice dei compagni di squadra, incorporamenti del linguaggio. La denominazione coerente è un'arma di produttività potente, perché significa che quando indovini il nome di qualcosa, di solito indovini giusto. E ' file.SaveTo(), File.saveTo(), file.save_to(), FILE.save_to()? La convenzione di denominazione te lo dirà.

Portare le tue preferenze personali in ogni lingua che incontri è particolarmente pericoloso, perché prima di tutto ogni lingua ha la sua 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.

Solo un esempio: in C #, tipi e variabili vivono in spazi dei nomi separati; il compilatore è abbastanza intelligente da conoscere 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 necessita di una convenzione di denominazione che distingua i tipi dalle variabili, mentre C # no.

Sono sorpreso che nessun altro l'abbia detto, ma penso che la differenza di capitalizzazione sia incredibilmente utile per un motivo: è bello e conveniente poter sapere se una variabile ha solo un ambito locale o meno. Se la variabile è locale di quanto non mi preoccupi tanto degli effetti collaterali della sua modifica, come il refactoring del nome. Quindi mi piace una convenzione che distingue i membri della classe rispetto alle variabili della classe privata rispetto alle variabili locali.

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

E un bel po 'di questo potrebbe essere lasciato fuori dal mio stile peggiore anni fa, quando i metodi non avevano le stesse probabilità di adattarsi a uno schermo.

Sembra più una questione di convenzioni piuttosto che una specifica convenzione.

Per ogni convenzione infranta, 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 attraverso le aziende o anche per divertimento. Più casuale è il codice, più difficile e costoso è lavorare. Come 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 ciò che è più efficiente per l'adozione di massa. Questo incoraggia la collaborazione e rimuove le barriere estranee che non dovrebbero essere lì in primo luogo.

Per quanto riguarda la tua vera convenzione, CapitalCamelCase è in genere riservato ai nomi di classe (o in Javascript, costruttori). Se vedo una variabile maiuscola, un'ipotesi istruita detterà che dovrò istanziarla per usarla. Se questo è sbagliato, sarò incazzato che il codice non stia seguendo gli standard della community. 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 completo dovrebbe essere riservato per proprietà e metodi vuoti. La variabile locale e i metodi che restituiscono un valore devono avere la prima parola in minuscolo" e perché è una convenzione standard.

Altri programmatori stanno tirando su il tuo codice in questo momento e pensano che questa sia una proprietà ed è davvero una variabile locale, rendendo il tuo lavoro più difficile.

Come altri hanno detto nessun vero motivo, tranne che per ottenere una convenzione di denominazione giù pat. Se riesci a mettere tutta la tua squadra nella stessa pagina, probabilmente puoi risparmiare un po 'di tempo. Per esempio, personalmente ho iniziato una questione di standard di codifica che è andata in questo e abbiamo usato camelCase per tutte le varianti private e le cose passate da Val, mentre abbiamo usato PascalCase per cose che sono pubbliche e cose passate da Ref.

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

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

I simboli minuscoli e maiuscoli hanno grandi differenze semantiche in Haskell, inoltre differiscono leggermente in Scala e li ho usati entrambi. Le altre lingue che uso non fanno alcuna 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 dipende dalle aspettative.

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

Questo è probabilmente ciò che sta accadendo nel tuo caso.

Inoltre, è utile essere in grado di dire quale ruolo gioca una variabile osservando la prima lettera ed evita gli scontri tra il nome di un'istanza e il nome di una classe.

Le lettere minuscole dovrebbero essere usate per le variabili locali per facilitare la digitazione (tasto speed / no shift). La maiuscola viene utilizzata per aiutare la leggibilità separando le parole all'interno di un nome. Il codice con nomi di variabili locali a parola singola (che dovrebbe essere comune) è veloce e facile da digitare. L'uso di lettere maiuscole 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 di cammello.

Sono d'accordo con l'OP qui. camelCase sembra sbagliato. Concordo anche con il fatto che quello è lo standard e dobbiamo attenerci allo stesso standard o qual è il punto di avere uno standard. Ha anche senso che PascalCaps sia usato per metodi ecc. E camelCase per le tue variabili ecc. Come modo di differenziare quando non usi un IDE che colora i metodi per te.

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