Convenzioni di denominazione: camelCase contro underscore_case? quali sono i tuoi pensieri al riguardo? [chiuso]

Sono daccordo che dipende dalla lingua che stai utilizzando in una certa misura; il codice tende a sembrare più ordinato quando i nomi dei tuoi simboli seguono la stessa formattazione regime come i built-in del linguaggio e le librerie di archivio.

Ma dove cè una scelta, preferisco i caratteri di sottolineatura al caso del cammello, per una semplice ragione: trovo quello stile più facile da leggere. un esempio: quale trovi più leggibile? Questo:

aRatherLongSymbolName 

o questo:

a_rather_long_symbol_name 

Trovo la versione con trattino basso molto più semplice leggere. Il mio cervello può ignorare i caratteri di sottolineatura molto più facilmente di quanto possa rilevare i contorni minuscoli / maiuscoli nel caso del cammello, specialmente dove i confini sono tra glifi che sembrano simili ad altri glifi del caso opposto, o numeri (I/l, O/0, t/I e così via). Ad esempio, questa variabile booleana memorizza un valore che indica se un igloo è stato costruito o meno con unadeguata autorizzazione edilizia (senza dubbio un caso duso comune per tutti noi):

isIllicitIgloo 

Trovo questa versione molto più facile da leggere:

is_illicit_igloo 

Forse anche peggio di un nome di simbolo difficile da leggere è un nome di simbolo di facile lettura. I buoni nomi dei simboli sono auto-documentanti, il che per me significa che dovresti essere in grado di leggerli e comprenderne il significato a colpo docchio. (Sono sicuro che leggiamo tutti i codici stampati a letto per piacere, ma a volte anche noi sguazziamo in fretta.) Trovo spesso con i nomi dei simboli delle custodie dei cammelli che è facile leggerli male e avere unimpressione sbagliata della semantica di un simbolo.

Commenti

• Un problema con i trattini bassi: lusabilità. Per la maggior parte delle tastiere (europee), digitare il segno di sottolineatura richiede di tenere premuto premuto il tasto MAIUSC. È necessario farlo anche per camelCase, ma posso comodamente tenere premuto MAIUSC con il mignolo e digitare qualsiasi lettera, ma poiché il tasto di sottolineatura si trova proprio accanto al tasto MAIUSC, premendo entrambi contemporaneamente è piuttosto imbarazzante e interrompe il flusso di battitura.
• Per il primo, in realtà ho trovato camelCase più facile da leggere, anche se il secondo è ovviamente diverso.
• Questo dipende davvero da cosa ' sono abituato. Trovo camelCases più facili da leggere e inoltre ' sono più brevi dei nomi di trattini bassi equivalenti.
• Io odio digitare caratteri di sottolineatura.
• Il punto di " usabilità " è irrilevante per questo. Il codice viene tipicamente scritto una sola volta da una persona, ma diciamo ' nellordine di 1-10 volte tenendo conto di alcune modifiche e della potenziale programmazione in coppia. Ma il codice viene in genere letto dozzine / centinaia / migliaia di volte da una o potenzialmente molte persone. Pertanto, rendere il codice facile da leggere è di molte dimensioni più importante che avere codice facile da scrivere.

Penso che dovresti usare la convenzione di denominazione adottata dalla tua piattaforma. underscore_case apparirà strano in codice C #, come camelCase in Ruby =)

Commenti

• La coerenza è una chiave. Che tu sia daccordo o meno con la convenzione locale, semplificherai il tuo tempo (e tutti gli altri ' s) essendo coerente. (A meno che la convenzione locale non sia essa stessa incoerenza.) Inoltre, la leggibilità è per lo più un argomento falso: leggi abbastanza codice ogni volta che ' scoprirai che cè poca differenza a meno che non decidi che è illeggibile.
• Pienamente daccordo. Penso solo che sia meglio usare le convenzioni della piattaforma invece di quelle personalizzate, perché ad esempio i nuovi ragazzi in team si sentiranno più a loro agio.
• Ma guai a quelli di noi che lavorano su due piattaforme con due convenzioni , dove alcuni preferiscono e altri preferiscono!
• Se la piattaforma ha 2 convenzioni, ' chiederei a tutti i membri del team di votare per la convenzione con cui sono a proprio agio =)

Onestamente, non importa finché tutti i membri del team utilizzano stesso schema. È probabile che luna o laltra sia più naturale per te, anche se la vera importanza è la leggibilità del codice a lungo termine e quindi è fondamentale che tutti aderiscano alle stesse regole di denominazione.

Commenti

• hai perfettamente ragione, tuttavia ' sto cercando di scoprire lopinione della gente sulla strega sarebbe meglio usare (lascia ' s per tutto il team) e perché … anche se capisco che alcune persone potrebbero essere abituate a qualche convenzione o altre si sentono più naturali con laltra.

Basandosi su una risposta la risposta di John Isaacks:

“onestamente il codice è più facile da leggere” Opinione o fatto?

Ho deciso di fare qualche ricerca e ho trovato questo documento . Che cosa ha da dire la scienza sullargomento?

1. Linvolucro del cammello ha una maggiore probabilità di correttezza di trattini bassi. (le probabilità sono superiori del 51,5%)
2. In media, la custodia del cammello ha impiegato 0,42 secondi in più , ovvero 13,5% in più.
3. La formazione non ha un impatto statisticamente significativo sul modo in cui lo stile influenza la correttezza.
4. Quelli con più formazione sono stati più veloci sugli identificatori nello stile della custodia del cammello.
5. Formazione in uno stile, influisce negativamente sul tempo di ricerca per altri stili.

Nel mio post sul blog sullargomento esamino il articolo scientifico e trarre la seguente conclusione.

Solo la lentezza del caso del cammello ( 2) è davvero rilevante per la programmazione, respingendo gli altri punti come irrilevanti a causa degli IDE moderni e della maggioranza degli utenti camelCase nello studio. La discussione (insieme a un sondaggio) può essere trovata nel post del blog.

Sono curioso di sapere come questo articolo potrebbe cambiare lopinione di qualcuno. 🙂

Commenti

• Ovviamente, ignori tutti gli altri punti a causa della tua preferenza per i trattini bassi e gli altri punti non ' ti aiutano nel tuo caso …
• @Charles: Sì e no, IMHO faccio buoni argomenti sul motivo per cui sono ignorabili, e alcuni di essi sono persino discussi come problematici dal giornale stesso. A documento di follow-up indaga alcuni dei problemi di questo documento e i risultati sono sottolineature a favore.

Copia i ragazzi più intelligenti

Nel caso dei linguaggi di programmazione, copia lo stile dello sviluppatore del linguaggio.

Ad esempio codice C esattamente come si fa in K & R.

Quindi quando qualcuno cerca di avviare una codifica noiosa stile di conversazione, posso dire loro “parlane con Dennis Ritche e fammi sapere cosa dice”.

Commenti

• Loriginale non è sempre il migliore. Ci sono molte cattive pratiche nel libro evangelico K & R su C. Prima che inizi una guerra infuocata … leggi alcune delle raccomandazioni MISRA.
• Non ' per dimenticare, K & R è stato scritto quando non cerano GUI-IDE. La maggior parte del lavoro è stata eseguita su terminali di caratteri 80×25, quindi lo spazio sullo schermo era limitato, fare if (...) { ha salvato una riga! Oggigiorno, cè ' più spazio sullo schermo: K & R sarebbe diverso se fosse scritto oggi con IDE GUI ad alta risoluzione e monitor multipli allestimenti?
• Sì, ma quando qualcuno dice che codifica C come K & R, ottiene oggetti di scena per essere vecchia scuola.
• @quickly_now , parlane con Dennis Ritchie e fammi sapere cosa dice!
• Adotto molta formattazione da MS: _internalToClassOnly, accessByGetter, PublicVariable.

In generale, preferisco camelCase. Tuttavia, ciò è dovuto al fatto che la maggior parte della mia carriera, ho lavorato in linguaggi e ambienti in cui le guide di stile normalmente raccomandano camelCase. (Java, ECMAScript, C ++). Tu, essendo una persona PHP, è probabile che tu abbia la preferenza opposta.

Detto questo, quando vai oltre treOrFourWords, o se usi initialisms comeXmlForExample, smette di essere così leggibile.

Questo è il motivo per cui emacs ci offre la modalità occhiali.

Commenti

• +1 per avermi fatto scoprire la modalità occhiali! Lho appena testato su un file di codice che utilizza camelCase e ho notato come ha subito iniziato ad avere un aspetto migliore (assemblaggio con un sacco di etichette in camelCase).
• Ok, cosè la modalità occhiali?
• gnu.org/software/emacs/ manual / html_node / emacs / Glasses.html

camelCase

Questo è uno dei pochi posti in cui sceglierò sempre la” capacità di digitazione “rispetto alla leggibilità. CamelCase è semplicemente più facile da digitare, ed essere più gentile con le dita vince su un leggero guadagno di leggibilità per me.

ovviamente supponendo che il progetto non si basi su una base di codice esistente con uno standard diverso.

Commenti

• Non ' non sono daccordo, scrivi il codice solo una volta, ma devi leggerlo più volte in seguito

È una domanda interessante, ci ho pensato molte volte. Ma non esiste una risposta definitiva, credo.

Seguendo le convenzioni “culturali” è una buona scelta. “Culturale” in questo caso indica le convenzioni stabilite nel team / azienda e fondamentalmente portano anche le convenzioni della lingua / piattaforma. Aiuta gli altri a leggere / utilizzare facilmente il tuo codice e non richiede ulteriori sforzi e tempo per capire il tuo codice.

A volte è interessante rompere le notazioni accettate. Uno dei miei piccoli progetti (su Python) Ho usato underscored_names per funzioni di utilità / metodi “protetti” e methodNames in stile Java per i metodi. Il mio team era felice con esso 🙂

Dipende dal linguaggio di programmazione.

Considero lutilizzo del caso in la stessa barca per decidere se utilizzare o meno la notazione ungherese:

• Python: underscore_case, nessuna notazione ungherese
• C ++: camelCase, notazione ungherese

Commenti

• @Kevin Cantu: In realtà il nome Javascript è in PascalCase anziché in camelCase …
• @Guffa: touch é!
• @Kevin Cantu: su JavaScript: XMLHttpRequest < – Odio questo nome wi è una passione.
• hypotheticalReasonsToNukeRedmond.push (XMLHttpRequest)
• @Lionel: In realtà la notazione ungherese non è quasi mai usata in C ++, poiché C ++ controlla già i tuoi tipi. È ' più un artefatto storico che altro.

Entrambi!

Sviluppo molto in CakePHP e utilizzo CamelCase o $underscored_vars, nel modo seguente (anche al di fuori dei progetti CakePHP):

1. nomi di file – /lowercased_underscored.php Tipico, ma degno di nota.
2. classes – class CamelCase extends ParentObject. Tieni presente che, quando utilizzi CamelCase, il carattere iniziale non è minuscolo. Trovo che camelCase sembri davvero strano.
3. variabili – $are_variables_underscored === TRUE;
4. variabili che contengono istanze – $CamelCase = new CamelCase();
5. chiavi di matrice – $collection["underscored_keys"];
6. costanti – Penso tutti possono concordare sul fatto che le costanti debbano essere ALL_CAPS_AND_UNDERSCORED.
7. metodi – $CamelCase->foo_method_underscored();
8. metodi statici – CamelCase::just_like_regular_methods();

Commenti

• devono essere daccordo con te, visto che il primo carattere è più basso il caso mi fa impazzire! Odio camelCase con una passione.
• In Java, dove i nomi sono tipicamente camelCased, i nomi delle classi iniziano effettivamente con una lettera maiuscola. Questo serve per distinguerli dai nomi dei metodi.

Personalmente preferisco underscore_case perché lo trovo più leggibile, ma sono daccordo con gli altri rispondenti che sottolineano che la coerenza con la base di codice esistente è molto più importante.

Tuttavia, ho un controesempio per coloro che dicono ” segui la convenzione del tuo linguaggio e delle sue librerie “.

In passato abbiamo scritto codice C su Windows utilizzando underscore_case e chiamato PascalCase Funzioni Win32:

if (one_of_our_conditions_is_true()) { call_one_of_our_functions(); CallSystemFunction(); } 

La distinzione visiva tra i nomi delle nostre funzioni e i nomi delle funzioni di Microsoft era un aiuto piuttosto che un ostacolo, in quanto mostrava chiaramente quando il codice stava andando in “system land”.

Inoltre, sono stato in grado di cambiare le regole di evidenziazione della sintassi del mio editor per visualizzarle in colori diversi, il che ha fornito ulteriori indizi visivi quando si cercava di comprendere sezioni di codice non familiari (o anche le mie).

Mi piacciono molto i trattini-semplicemente-normali-di Dylan-come-sono-facili-da-scrivere-e-facili -to-read.

Come

result-code := write-buffer(file-stream, some-string) 

Ma immagino che, poiché questo linguaggio è abbastanza oscuro, questo è un po fuori tema. .. 🙁

Commenti

• Sono anche stanco di premere Maiusc per digitare i trattini bassi.
• Di solito non è possibile per i nomi delle variabili, poiché " – " di solito significa meno.

Mi è stato insegnato a usare camelCase alluniversità. Ho usato alcune convenzioni diverse negli ultimi anni, ma preferisco camelCase a qualsiasi altra cosa. Penso di ricordare di aver letto da qualche parte che camelCase è in realtà il più facile da leggere e da capire.

Commenti

• beh, ' non è più facile perché leggi da qualche parte, ' è più facile perché era il primo con cui hai lavorato e principalmente perché ci sei più abituato, ad esempio ' sono più a mio agio con underscore_case.
• come in i ' ho letto che è stato fatto uno studio e lho trovato migliore ..

Come la maggior parte delle persone ha detto: usa lo standard esistente. Se si tratta di un nuovo progetto, usa lo standard per il linguaggio e i framework che utilizzerai.

E non confonderti, non si tratta di leggibilità (che è soggettiva), si tratta di essere coerenti e professionali. Chiunque abbia lavorato in una base di codice con numerosi “standard” in corso capirà.

A volte uso un mix: module_FunctionName. Tutte le funzioni (non statiche) nei miei moduli iniziano con unabbreviazione di modulo.

Ad esempio una funzione per inviare il contenuto di un buffer sul bus I2C:

i2c_BufferSend() 

Lalternativa i2c_buffer_send non mostra una separazione abbastanza grande tra prefisso e nome della funzione. i2cBufferSend si mescola nel prefisso troppo (ci sono un certo numero di funzioni I2C in questo modulo).

i2c_Buffer_send potrebbe essere stata unalternativa, però.

La mia risposta è che ti adatti a ciò che funziona meglio per il tuo progetto (la tua lingua, la tua architettura SW, …) e volevo sottolineare che mescolare questi stili potrebbe essere utile.

myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase. I_respect_the_fact_that_some_could_think_otherwise_but_I_do_not_really_understand_why.

Commenti

• +1 per le ultime 2 righe, tuttavia non ti consiglio di combinare le convenzioni di denominazione, dovresti attenersi a una o laltraaltro.
• Finché la convenzione è ben definita (prefisso + trattino basso + PascalCase) …
• Mi piace usare trattini bassi per separare le parti di un nome che hanno semanticamente disgiunte scopi, soprattutto se la comunanza su entrambe le metà può essere significativa. Ad esempio, le routine Motor1_Start(), Motor2_Start(), Motor1_Stop() e Motor2_Stop() hanno una relazione che potrebbe essere meno chiara senza i trattini bassi.

Personalmente , Preferisco camelCase, ma in alcuni caratteri penso che i trattini bassi siano più facili da leggere.

Suggerirei che se hai bisogno di usare prefissi per differenziare insiemi di variabili, dovresti usare un linguaggio che ti consenta di creare spazi dei nomi o oggetti o qualcosa per contenere tali informazioni.

myName = 7 bobsName = 8 // :( me.name = 7 bob.name = 8 // :D 

Allo stesso modo, se hai bisogno di differenziare i tipi, perché non usare un linguaggio che li permetta?

var intThingy = 7; // :( int thingy = 7; // :) 

Una volta che hai capito bene e non stai usando il nome solo come metadati, non avrai nomi abbastanza lunghi da è molto importante che tu preferisca o meno quella pressione dei tasti in più.

Commenti

• Uno dei motivi per utilizzare camelCase o underscore_case è che non ' bisogno di trovare la definizione degli oggetti per discernere di cosa si tratta.

Allinizio, sono daccordo con dafmetal . È della massima importanza non mescolare stili di programmazione diversi. Farlo in uno stesso file è il peggio che puoi fare IMHO. Attraverso file diversi, è fonte di distrazione, ma non fatale.

La prossima cosa che devi fare è nominare regole che sono popolari per la lingua in cui stai scrivendo. Il mio codice C ++ per instnace, lo farà sembra diverso da qualcosa per Python ovviamente (PEP8 è una bella guida qui)

Puoi anche usare diverse convenzioni di denominazione per fare riferimento a cose diverse, tanto quanto probabilmente usi UPPER_CASE per le costanti (questo vale solo per alcune lingue ovviamente), puoi usare this_style per i nomi delle variabili locali, mentre usi camelCase per le variabili di istanza / membro. Tuttavia, potrebbe non essere necessario quando si dispone di elementi come self o this.

Aggiorna

Prendiamo un caso in cui hai la piattaforma Foo witch “t non consiglia alcuna convenzione di denominazione ed è la scelta del leader della squadra di sceglierne una. Tu sei il leader della squadra, perché dovresti scegliere camelCase o perché underscore_case.

Non ci sono vantaggi per uno sullaltro. Questa questione è molto soggettiva e una volta concordata, non farà la differenza. Ci sono sempre queste guerre religiose su queste piccole cose. Ma una volta che ti sei abituato a entrambi, le discussioni sembrano essere del tutto superflue.

Per citare Alex Martelli su una questione molto simile:

Certo, mi stanco, in Ruby, di digitare la sciocca “fine” alla fine di ogni blocco (piuttosto che semplicemente annullare il rientro) – ma poi riesco a evitare di digitare laltrettanto stupida “:” che Python richiede all inizio di ogni blocco, quindi è quasi un lavaggio :-). Altre differenze di sintassi come “@foo” rispetto a “self.foo”, o il significato più alto di case in Ruby vs Python, sono davvero irrilevanti per me.

Altri senza dubbio basano la loro scelta dei linguaggi di programmazione proprio su questi problemi, e generano i dibattiti più accesi – ma per me questo è solo un esempio di una delle leggi del Parkinson in azione ( limporto del dibattito su un problema è inversamente proporzionale alla reale importanza del problema ).

Fonte

Se sei il leader del team, scegli uno solo. Dal momento che uno non ha alcun vantaggio sullaltro, puoi semplicemente lanciare i dadi o scegliere quello che ti piace di più.

Ho letto diversi anni fa che i programmatori che non parlano inglese come prima lingua tendono a trovare il carattere di sottolineatura più facile da capire nel caso del cammello, ma non riesco a trovare il riferimento, e non ho idea se sia vero.

Per i linguaggi di programmazione che ho usato, come Java, Python, C ++, ho adottato un formato chiaro:

• ClassNamesArePascalCase
• methodNamesAreCamalCase
• variable_names_are_underscore
• CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES

Questo mi permette di discernere immediatamente con cosa ho a che fare. Ho scoperto che è utile mantenere per me stesso, e dovrebbe essere facile da seguire per qualcun altro che legge il codice. Penso che, come altri hanno detto, la coerenza sia la cosa più importante. Quindi trovo il mio formato essere abbastanza semplice da mantenere, fornendo al contempo chiare distinzioni tra i tipi di nomi. Potrei immaginare interface_Names_Are_Like_This e Abstract_Classes_Are_Like_This come possibili estensioni, ma sembrano essere più complicate da seguire e forse non altrettanto utile una distinzione da fare.

Ho anche trovato utile essere rigorosi e denominare le cose in PascalCase come un parser HTML come HtmlParser invece di HTMLParser o HTMLparser. Perché credo che sia più facile ricordare la regola rigida e mantenere più chiari i confini delle parole (sfortunatamente richiede errori di ortografia come HTML o SQL). Allo stesso modo con camelCase, htmlParserMethod invece di HTMLParserMethod o HTMLparserMethod.

UPDATE :

Da allora ho trovato luso nellespandere queste regole per includere variabili private.- _private_variable_names_are_prefixed_with_an_underscore – _PRIVATE_CONSTANT_VARIABLES_ARE_PREFIXED_WITH_AN_UNDERSCORE

In Java, questo significa che i campi privati sono per definizione in uno spazio dei nomi diverso dalle variabili locali, il che significa che puoi saltare il iv id0 4_div4 privato campi. Altri formati ho “visto il prefisso” m “, ma questi formati usano anche camelCase per i nomi delle variabili. Questo mi permette anche di fare una distinzione tra i campi a cui si dovrebbe accedere solo internamente dalla classe (e rendendola super chiara quando “sta accadendo al di fuori della classe object._field_x si distingue).

Se dipendesse da me, non imposterei o suggerirei luso di uno stile particolare perché, come programmatori, dovremmo essere in grado di leggere un simbolo IfItIsInCamelCase o in_underscore_space o anche in_SomeOtherStyle e capire cosa significa. Dover passare un po di tempo ad analizzare il simbolo non è un grande sovraccarico nel grande schema di cose.

Ora, largomento principale di una convenzione immagino sia che tu sappia in anticipo qual è il formato di un nome di funzione / variabile e non hai bisogno di cercarlo – è LoadXMLFile, loadXMLFile , LoadXmlFi le, load_xml_file? Ora, vorrei contrastare questo argomento dicendo “Ottieni un IDE che supporti il completamento automatico in stile intellisense!” (non sempre possibile però).

Alla fine, però, non importa quale stile usi perché al compilatore / interprete non interessa davvero. Limportante è che il nome sia utile:

NumberOfPrisonersReleasedByAccident manufacturer_name distance_EarthToMoon 

Tre stili diversi, ma sai esattamente cosa fa ciascuno di essi.

Commenti

• Chiedo di dissentire, laspetto della fonte è importante. Vedi " La teoria delle finestre rotte del programmatore pragmatico " '. La variazione della convenzione di denominazione peggiora laspetto. pragprog.com/the-pragmatic-programmer/extracts/software-entropy
• @Gauthier: sebbene sia daccordo con ' finestra rotta ' idea, non ' penso che luso delle maiuscole nei simboli costituisca un ' finestra rotta '. Il codice disposto in modo casuale lo è certamente, e il mio progetto attuale ha sicuramente molto di quello che cerco di riordinare ogni volta che posso.
• Sono daccordo. Posso leggere tutti e tre ugualmente bene. Non ' importa. Uso semplicemente qualunque cosa stia usando il file, poi qualunque cosa il linguaggio propone (python) e poi qualunque cosa ritengo che il progetto sarà meglio servito. (Ero solito programmare in gwbasic, ed era tutto maiuscolo – i bei vecchi tempi!)

Può sembrare sciocco, ma non mi piacciono i trattini bassi perché il carattere di sottolineatura è sottile e si nasconde in più righe di testo e mi manca. Inoltre, in alcuni (molti) editor di testo e / o ambienti di sviluppo, quando fai doppio clic su un nome di token per evidenziarlo in modo da copiarlo o trascinarlo e rilasciarlo, il sistema non evidenzierà lintero token, evidenzia solo una parte del token, tra trattini bassi adiacenti. Questo mi fa impazzire.

Tendo a preferire camelCase per lo stupido motivo che svolgo la maggior parte del mio sviluppo in Eclipse (per Java, PHP e JavaScript) e quando Ctrl + ← o Ctrl + → attraverso le parole, in realtà si ferma ai confini camelCase.

Cioè: myIntVariable verrebbe trattato da Eclipse come 3 parole quando Ct rl + ←   → ” attraverso di essa.

Lo so “una strana stranezza, ma mi trovo a preferire la possibilità di modificare le parole centrali in un nome camelCase.