I vari token nel vostro codice (variabili, classi, funzioni, namespace, ecc.) possono essere nominati usando uno di questi tre stili, parlando in senso lato:
- Camel Case (es: someVar, someClass, somePackage.xyz).
- Pascal Case (es: SomeVar, SomeClass, SomePackage.xyz).
- Corsivi (es: some_var, some_class, some_package.xyz).
Nel camel casing, i nomi iniziano con una minuscola ma ogni parola propria nel nome è maiuscola e così pure gli acronimi. Per esempio, i token comunemente usati in molti linguaggi come toString, checkValidity, lineHeight, timestampToLocalDateTime, ecc. sono tutti esempi di camel casing.
Il casing pascal è simile al camel casing tranne che la prima lettera inizia con una maiuscola (SomeClass invece di someClass).
Nel casing underscore, tutto è in minuscolo (anche gli acronimi) e le parole sono separate da underscore (some_class, some_func, some_var, etc). Questa convenzione è anche popolarmente conosciuta come snake case.
L’idea generale è che puoi usare qualsiasi convenzione nel tuo progetto finché sei coerente nell’usarla ovunque. Ma quando codifichi per un grande progetto o team, dovresti conformarti alla norma di ciò che viene usato lì. Quindi, è utile essere consapevoli delle convenzioni tipiche dei vari linguaggi di programmazione.
La pratica generale per un linguaggio in stile C come Java o JS è di usare camelCase per tutte le variabili e i membri degli oggetti (proprietà & metodi), e PascalCase per i nomi delle classi e i costruttori. Gli spazi dei nomi (o pacchetti nel mondo Java) sono di solito in camelCase.
Ma alcuni linguaggi fanno un’eccezione a questo. C#, per esempio, usa PascalCase per gli spazi dei nomi e anche per i metodi pubblici. Quindi, la funzione principale (o punto di ingresso) è sempre static void main() in java ma static void Main() in C# (notare la maiuscola della parola “Main”).
Alcuni linguaggi che non derivano la loro sintassi dal C (come Python & Ruby) usano i trattini bassi per quasi tutto tranne i nomi delle classi. Quindi, è sempre sys.base_prefix invece di sys.basePrefixdatetime invece di DateTimestr.splitlines() invece di str.splitLines() in python.
Nel caso della libreria standard di python, ho notato che anche le classi usano i trattini bassi a volte, il che è un’incongruenza. Per esempio, datetime.datetime è una classe e anche csv.excel_tab. I framework e le librerie popolari però (come django e flask) usano il camel case per le classi.
Un’incoerenza simile è in PHP. Il linguaggio si sta evolvendo da underscore a camel casing negli ultimi anni, ma alcuni vecchi token infestano ancora quel linguaggio. Per esempio, mysqli::set_local_infile_default vs PDOStatement::debugDumpParams.
Quindi, alla fine, si tratta di una scelta personale quando si inizia un progetto. Ma aiuta sapere quali sono le convenzioni solitamente seguite nei progetti open source popolari nella lingua di tua preferenza.
Aggiornamento
C’è anche un quarto caso come sottolineato da @ovais, cioè il caso kebab. È molto simile al caso underline, tranne che le sottolineature sono sostituite da trattini (dashes). Così, some_func diventa some-func che ovviamente non è permesso perché il trattino non è usato per nominare i token in quanto è già un built-in per l’operatore meno in molti linguaggi di programmazione. Dove il caso kebab è usato più frequentemente è per creare classi nei vostri fogli di stile css! Nomi come main-divmain-navbar e article-footer sono comunemente usati dagli sviluppatori web mentre scrivono il loro HTML/CSS. Questa convenzione è fondamentalmente il caso kebab.
Aggiornamento
Come dice @patrykrudnicki, le costanti sono gestite diversamente. Nella mia esperienza, l’underscore completo (SOME_CONST) è una convenzione popolare per le costanti in molti linguaggi tra cui Java, PHP e Python.
Aggiornamento
Per riassumere, questa è la convenzione tipica o generalmente seguita nei linguaggi di programmazione open source più usati:
| Token | python | Java/JS | PHP |
|---|---|---|---|
| variabile | under_score | camelCase | mix (spostandosi verso camelCase) |
| funzione | under_score() | camelCase() | mix (spostandosi verso camelCase()) |
| costante | UNDER_SCORE | UNDER_SCORE | UNDER_SCORE |
| classe | PascalCase | PascalCase | mix (spostandosi verso PascalCase) |
| namespace | under_score | camelCase | mix (muovendosi verso PascalCase) |
Alcuni link utili:
- https://softwareengineering.stackexchange.com/questions/196416/whats-the-dominant-naming-convention-for-variables-in-php-camelcase-or-undersc
- https://stackoverflow.com/questions/149491/pascal-casing-or-camel-casing-for-c-sharp-code
- https://www.c-sharpcorner.com/forums/when-to-use-camel-case-and-pascal-case-c-sharp
- https://softwareengineering.stackexchange.com/questions/53498/what-is-the-philosophy-reasoning-behind-cs-pascal-casing-method-names