it-swarm.it

Convenzioni di denominazione: camelCase contro underscore_case? cosa ne pensi?

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 penso ancora 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

post scriptum per favore scusa il mio cattivo inglese

Edit

Alcuni aggiornamenti prima:

  • la piattaforma utilizzata è PHP (ma non mi aspetto rigoroso PHP risposte relative alla piattaforma, chiunque può condividere i propri pensieri su quale sarebbe il migliore da usare, cioè 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?

post scriptum grazie a tutti per la pronta risposta finora

70
poelinca

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 un semplice motivo: 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 i caratteri di sottolineatura molto più facilmente di quanto possa rilevare i limiti 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, eccetera). 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 che questa versione sia lotto 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.

84
Simon Whitaker

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

97
Alexey Anufriyev

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.

20
dafmetal

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'intelaiatura del cammello ha una maggiore probabilità di correttezza rispetto ai caratteri di sottolineatura. (le probabilità sono più alte del 51,5%)
  2. In media, il caso del cammello impiegava 0,42 secondi in più , che è del 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 sono stati più veloci sugli identificatori nello stile del caso dei cammelli.
  5. L'allenamento in uno stile, influisce negativamente sul tempo di ricerca per altri stili.

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

Solo la lentezza del caso del cammello (2) è veramente rilevante per la programmazione, respingendo gli altri punti come irrilevanti a causa di IDE moderni e la 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. :)

20
Steven Jeuris

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 "portalo con Dennis Ritche e fammi sapere cosa dice".

11
Mark Harrison

In generale, preferisco camelCase. Tuttavia, questo perché la 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 treOrFourWords o se usi inizialismi come XmlForExample, smette di essere così leggibile.

Ecco perché emacs ci offre la modalità occhiali.

10
Paul Butcher

camelCase

Questo è uno dei pochi posti in cui sceglierò sempre la "capacità di scrivere" 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.

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

8
AShelly

È 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_names per funzioni di utilità/metodi "protetti" e stile Java methodNames per metodi. La mia squadra era felice :)

7
duros

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
6
Lionel

Tutti e due!

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

  1. nomi dei file - /lowercased_underscored.php Tipico, ma degno di nota.
  2. classi - class CamelCase extends ParentObject. Si noti che, quando si utilizza CamelCase, il carattere iniziale non è minuscolo. Trovo camelCase un aspetto davvero strano.
  3. variabili - $are_variables_underscored === TRUE;
  4. variabili che contengono istanze - $CamelCase = new CamelCase();
  5. chiavi dell'array - $collection['underscored_keys'];
  6. costanti - Penso che tutti possano concordare 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();
6
Stephen

Personalmente preferisco underscore_case perché 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_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 è 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 non familiari (o anche la mia).

5
Paul Stephenson

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 ... :(

5
Kosta

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.

4
Ross

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.

4
Kevin Cantu

Come la maggior parte delle persone ha menzionato, utilizzare 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à.

4
Colin Goudie

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_send non mostra una separazione abbastanza grande tra prefisso e nome della funzione. i2cBufferSend mescola troppo il prefisso (in questo modulo ci sono molte funzioni I2C).

i2c_Buffer_send potrebbe essere stata 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 il mix di questi stili potrebbe essere utile.

myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase. I_respect_the_fact_that_some_could_think_otherwise_but_I_do_not_really_understand_why.

4
Gauthier

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 di Word (purtroppo richiede errori di ortografia come HTML o SQL). Allo stesso modo con 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, questo significa che i campi privati ​​sono per definizione in uno spazio dei nomi diverso rispetto alle variabili locali, il che significa che puoi saltare il this. su 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 chiaro super quando accade al di fuori della classe object._field_x spicca).

2
Dandre Allison

All'inizio sono d'accordo con dafmetal. È estremamente importante non mescolare 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 il linguaggio in cui stai scrivendo. Il mio codice C++ per instnace, avrà un aspetto 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 self o this.

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 ':' che Python richiede al start di ogni blocco, quindi è quasi un lavaggio :-). Altre differenze di sintassi come '@foo' rispetto a 'self.foo', o il significato più alto 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'importo in discussione su un problema è inversamente proporzionale all'importanza effettiva del problema ).

Source

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ù.

2
phant0m

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.

2
Ed Harper

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 supporta il completamento automatico in stile intellisense!" (Non sempre possibile però).

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

NumberOfPrisonersReleasedByAccident
manufacturer_name
distance_EarthToMoon

Tre stili diversi, ma sai esattamente cosa fa ciascuno.

1
Skizz

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 Ctrl+ o Ctrl+ attraverso le parole, in realtà si ferma ai confini di camelCase.

Ad esempio: myIntVariable verrebbe trattato da Eclipse come 3 parole quando Ctrl+← →attraverso di esso.

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

0
Bassam

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.

0
Charles Bretana