Convenzioni di denominazione: camelCase contro underscore_case? cosa ne pensi? [chiuso]

Sto usando underscore_case da circa 2 anni e recentemente sono passato a camelCase a causa del nuovo lavoro (ho usato quello successivo per circa 2 mesi e continuo a pensare che underscore_case sia più adatto a grandi progetti in cui sono coinvolti molti programmatori, principalmente perché il codice è più facile da leggere).

Ora tutti al lavoro usano camelCase perché (così si dice) il codice sembra più elegante.

Cosa ne pensi di camelCase o underscore_case

ps per favore scusa il mio cattivo inglese

modificare

Alcuni aggiornamenti prima:

• la piattaforma utilizzata è PHP (ma non mi aspetto risposte rigorose relative alla piattaforma PHP, chiunque può condividere i propri pensieri su quale sarebbe il migliore da usare, ecco perché sono venuto qui in primo luogo)

• Uso camelCase come tutti gli altri membri del team (proprio come molti di voi raccomandano)

• usiamo Zend Framework che raccomanda anche camelCase

Alcuni esempi (relativi a PHP):

• Il framework Codeigniter raccomanda underscore_case e onestamente il codice è più facile da leggere.

• ZF consiglia CamelCase e non sono l'unico a pensare che il codice ZF sia un po 'più difficile da seguire.

Quindi la mia domanda verrebbe riformulata:

Prendiamo un caso in cui hai la piattaforma Foo che non raccomanda alcuna convenzione di denominazione ed è la scelta del leader del team di sceglierne una. Sei il capo squadra, perché dovresti scegliere camelCase o perché underscore_case?

ps grazie a tutti per la pronta risposta finora

Sono d'accordo che dipende dalla lingua che stai usando in una certa misura; il codice tende ad apparire più ordinato quando i nomi dei simboli seguono lo stesso regime di formattazione dei built-in e delle librerie di magazzino del linguaggio.

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

aRatherLongSymbolName

o questo:

a_rather_long_symbol_name

Trovo che la versione di sottolineatura sia molto più facile da leggere. Il mio cervello può ignorare le sottolineature molto più facilmente di quanto non in grado di rilevare i confini minuscole / maiuscole in caso di cammello, in particolare dove i confini sono tra i glifi che sembrano simili ad altri glifi del caso opposto, o numeri ( I/l, O/0, t/I, ecc). Ad esempio, questa variabile booleana memorizza un valore che indica se un Igloo è stato costruito o meno con un'autorizzazione di pianificazione adeguata (senza dubbio un caso d'uso comune per tutti noi):

isIllicitIgloo

Trovo questa versione molto più facile da leggere:

is_illicit_igloo

Forse anche peggio di un nome simbolo difficile da leggere è un nome simbolo facile da leggere. I nomi di buoni simboli sono auto-documentanti, il che per me significa che dovresti essere in grado di leggerli e comprenderne il significato a colpo d'occhio. (Sono sicuro che tutti leggiamo le stampe di codici a letto per piacere, ma a volte anche noi ci affrettiamo anche in fretta.) Spesso trovo con i nomi dei simboli delle custodie per cammelli che è facile leggerle erroneamente e avere l'impressione sbagliata di un semantica del simbolo.

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

Onestamente, non importa se tutti nella squadra usano lo stesso schema. Le probabilità sono l'una o l'altra è 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.

Sulla base di 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 sull'argomento?

1. L'involucro del cammello ha una maggiore probabilità di correttezza rispetto ai caratteri di sottolineatura. (le probabilità sono più alte del 51,5%)
2. In media, la custodia del cammello ha impiegato 0,42 secondi in più , il 13,5% in più.
3. La formazione non ha alcun impatto statisticamente significativo su come lo stile influenza la correttezza.
4. Quelli con più addestramento erano più veloci sugli identificatori nello stile della custodia di cammello.
5. L'allenamento in uno stile, influisce negativamente sul tempo di ricerca per altri stili.

Nel mio post sul blog sull'argomento, rivedo il documento scientifico e faccio la seguente conclusione.

Solo la lentezza del caso cammello (2) è veramente rilevante per la programmazione, respingendo gli altri punti come irrilevanti a causa dei moderni IDE e della maggior parte degli utenti di camelCase nello studio. La discussione (insieme a un sondaggio) è disponibile sul post del blog.

Sono curioso di sapere come questo articolo potrebbe cambiare la propria opinione. :)

Copia i ragazzi più intelligenti

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

Ad esempio, codice C esattamente come in K&R.

Quindi, quando qualcuno cerca di iniziare una noiosa conversazione in stile codice, posso dire loro "tiralo fuori con Dennis Ritche e fammi sapere cosa dice".

In generale, preferisco camelCase. Tuttavia, ciò è dovuto al fatto che nella maggior parte della mia carriera ho lavorato in lingue 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 le treOrFourWords o se usi inizialismi come XmlForExample, smette di essere così leggibile.

Ecco perché emacs ci offre la modalità occhiali.

camelCase

Questo è uno dei pochi posti in cui sceglierò sempre l'abilità del tipo piuttosto che la leggibilità. CamelCase è semplicemente più facile da scrivere ed essere più gentile con le dita vince su un leggero guadagno di leggibilità per me.

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

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

Seguendo le convenzioni "culturali" è stata una buona scelta. "Culturale" in questo caso significa convenzioni stabilite nel team / azienda e sostanzialmente portano anche le convenzioni lingua / piattaforma. Aiuta gli altri a leggere / utilizzare facilmente il codice e non richiede ulteriori sforzi e tempo per comprendere il codice.

A volte è interessante rompere le notazioni accettate. Uno dei miei piccoli progetti (su Python) ho usato underscored_namesper funzioni di utilità / metodi "protetti" e stile Java methodNamesper metodi. La mia squadra era felice :)

Dipende dal linguaggio di programmazione.

Considero di utilizzare il caso nella stessa barca per usare o meno la notazione ungherese:

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

Entrambi!

Faccio molto sviluppo in CakePHP e utilizzo uno CamelCaseo $underscored_vars, nel modo seguente (anche al di fuori dei progetti CakePHP):

1. nomi di file : /lowercased_underscored.phptipici, ma vale la pena menzionarli.
2. classi - class CamelCase extends ParentObject. Si noti che, durante l'utilizzo CamelCase, il carattere iniziale non è minuscolo. Trovo camelCasedi guardare davvero strano.
3. variabili -$are_variables_underscored === TRUE;
4. variabili che contengono istanze -$CamelCase = new CamelCase();
5. chiavi array -$collection['underscored_keys'];
6. costanti - Penso che tutti possano essere d'accordo sul fatto che le costanti dovrebbero essere ALL_CAPS_AND_UNDERSCORED.
7. metodi -$CamelCase->foo_method_underscored();
8. metodi statici -CamelCase::just_like_regular_methods();

Personalmente preferisco underscore_caseperché lo trovo più leggibile, ma sono d'accordo con gli altri risponditori 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 della tua lingua e delle sue biblioteche".

In passato abbiamo scritto codice C su Windows usando underscore_casee chiamato PascalCasefunzioni 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 è stata un aiuto piuttosto che un ostacolo, come ha mostrato chiaramente quando il codice stava andando in "terra di sistema".

Inoltre, sono stato in grado di modificare le regole di evidenziazione della sintassi del mio editor per visualizzarle in diversi colori, il che ha fornito ulteriori indizi visivi quando ho cercato di comprendere sezioni di codice sconosciute (o anche la mia).

Mi piacciono molto i trattini di Dylan come normali, facili da scrivere e da leggere.

Piace

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

Ma immagino che questo linguaggio sia abbastanza oscuro, questo è un po 'fuori tema ... :(

Mi è stato insegnato a usare camelCase all'università. 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 capire.

Come molti hanno già detto - Usa lo standard esistente. Se si tratta di un nuovo progetto, utilizzare lo standard per la lingua e i framework che verranno utilizzati.

E non ti confondere, 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 un'abbreviazione di un modulo.

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

i2c_BufferSend()

L'alternativa i2c_buffer_sendnon mostra una separazione abbastanza grande tra prefisso e nome della funzione. i2cBufferSendmescola troppo il prefisso (in questo modulo ci sono molte funzioni I2C).

i2c_Buffer_send avrebbe potuto essere un'alternativa, però.

La mia risposta è che ti adatti a ciò che funziona meglio per il tuo progetto (la tua lingua, la tua architettura SW, ...), e ho voluto 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.

Personalmente, preferisco camelCase, ma in alcuni caratteri penso che i caratteri di sottolineatura siano più facili da leggere.

Vorrei suggerire che se è necessario utilizzare prefissi per differenziare insiemi di variabili, è necessario utilizzare un linguaggio che 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 è necessario differenziare i tipi, perché non utilizzare una lingua che li consenta?

var intThingy = 7; // :(

int thingy = 7;    // :)

Una volta che hai ragione, e non stai solo usando il nome come metadati, allora non avrai abbastanza nomi lunghi che contano molto se preferisci quel tasto aggiuntivo o meno.

All'inizio sono d'accordo con dafmetal. È della massima importanza che non si mischino diversi stili di programmazione. Fare questo in uno stesso file è il peggio che puoi fare IMHO. Attraverso diversi file, è fonte di distrazione, ma non fatale.

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

Puoi anche usare convenzioni di denominazione diverse per fare riferimento a cose diverse, per quanto probabilmente usi UPPER_CASE per le costanti (questo vale ovviamente solo per alcune lingue), puoi usare this_style per nomi di variabili locali, mentre usi camelCase per istanza / membro variabili. Questo potrebbe non essere necessario quando hai cose come selfo thiscomunque.

Aggiornare

Prendiamo un caso in cui hai la piattaforma Foo witch non raccomanda alcuna convenzione di denominazione ed è la scelta del leader del team di sceglierne una. Sei il capo squadra, perché dovresti scegliere camelCase o perché underscore_case.

Non ci sono davvero vantaggi per l'uno rispetto all'altro. Questa questione è molto soggettiva e, una volta concordata, non farà alcuna differenza. Ci sono sempre queste guerre di religione su queste piccole cose. Ma una volta che ti sei adattato 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 "fine" sciocca alla fine di ogni blocco (piuttosto che solo unindenting) - ma poi riesco a evitare di digitare ugualmente la sciocca ":" di cui Python richiede l' inizio di ogni blocco, quindi è quasi un lavaggio :-). Altre differenze di sintassi come '@foo' rispetto a 'self.foo', o il significato più elevato del caso in Ruby vs Python, sono davvero altrettanto irrilevanti per me.

Altri senza dubbio basano la loro scelta di linguaggi di programmazione proprio su tali questioni e generano i dibattiti più importanti - ma per me questo è solo un esempio di una delle leggi del Parkinson in azione ( l'ammontare del dibattito su una questione è inversamente proporzionale alla questione importanza reale ).

fonte

Se sei il caposquadra, basta andare con uno. Dal momento che uno non ha alcun vantaggio rispetto all'altro, puoi semplicemente lanciare dadi o scegliere quello che ti piace di più.

Ho letto diversi anni fa che i programmatori che non parlano l'inglese come prima lingua tendono a trovare il carattere di sottolineatura più facile da capire quel caso di 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 da mantenere per me stesso e dovrebbe essere facile da seguire per qualcun altro che legge il codice. Penso che come altri abbiano menzionato la coerenza sia molto importante. Quindi trovo che il mio formato sia 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_Queste possibili estensioni, ma sembra essere più complicato da seguire e forse non utile una distinzione da fare.

Ho anche trovato utile essere severi e nominare 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 (purtroppo richiede errori di ortografia come HTML o SQL). Analogamente a camelCase, htmlParserMethod anziché HTMLParserMethod o HTMLparserMethod.

AGGIORNAMENTO :

Da allora ho trovato l'uso nell'espansione di queste regole per includere variabili private. - _private_variable_names_are_prefixed_with_an_underscore - _PRIVATE_CONSTANT_VARIABLES_ARE_PREFIXED_WITH_AN_UNDERSCORE

In Java, ciò significa che i campi privati ​​si trovano per definizione in uno spazio dei nomi diverso rispetto alle variabili locali, il che significa che è possibile saltare i this.campi privati. Altri formati ho visto il prefisso con " m", ma quei formati usano anche camelCase per i nomi delle variabili. Questo mi permette anche di fare una distinzione tra i campi ai quali dovrebbe accedere la classe solo internamente (e renderlo super chiaro quando si verifica al di fuori della classe object._field_xsi distingue).

Se dipendesse da me, non imporrei o suggerirei l'uso di uno stile particolare perché, come programmatori, saremmo in grado di leggere un simbolo IfItIsInCamelCase o in_underscore_space o persino in_SomeOtherStyle e capire cosa significhi. Dover passare una piccola quantità di tempo ad analizzare il simbolo non è un grande sovraccarico nel grande schema delle cose.

Ora, l'argomento principale per una convenzione credo sia che tu sappia in anticipo quale sia il formato di una funzione / nome di variabile e non hai bisogno di cercarlo - è LoadXMLFile, loadXMLFile, LoadXmlFile, load_xml_file? Ora, vorrei contrastare tale argomento dicendo "Ottieni un IDE che supporti il ​​completamento automatico in stile intellisense!" (non sempre possibile però).

Alla fine, tuttavia, non importa quale stile usi perché il compilatore / interprete non se ne frega davvero. L'importante è che il nome sia utile:

NumberOfPrisonersReleasedByAccident
manufacturer_name
distance_EarthToMoon

Tre stili diversi, ma sai esattamente cosa fa ciascuno.

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

Tendo a preferire camelCase per il motivo sciocco che faccio la maggior parte del mio sviluppo in Eclipse (per Java, PHP e JavaScript) e quando I Ctrl+ ←o Ctrl+ →attraverso le parole, si ferma effettivamente ai confini di camelCase.

Vale a dire: myIntVariablesarebbe trattato da Eclipse come 3 parole quando Ctrl+ ← →'ci passa attraverso.

So che è una strana stranezza, ma mi trovo a preferire la possibilità di modificare le parole medie in un nome camelCase.