Stili di scrittura e convenzioni spiegati
I nomi nel codice, nei file, negli URL e nei titoli seguono convenzioni diverse a seconda del linguaggio e del formato. Questa guida riassume gli stili comuni, dove si usa ciascuno e i dettagli che spesso fanno inciampare: acronimi, numeri, titoli e lettere al di fuori dell’inglese.
Gli stili comuni
| Stile | Esempio | Come si forma |
|---|---|---|
| camelCase | orderTotal | Prima parola minuscola, le successive con l’iniziale maiuscola, senza separatori |
| PascalCase | OrderTotal | Ogni parola con l’iniziale maiuscola, senza separatori |
| snake_case | order_total | Minuscolo, parole unite da _ |
| CONSTANT_CASE | ORDER_TOTAL | Maiuscolo, parole unite da _ |
| kebab-case | order-total | Minuscolo, parole unite da - |
| dot.case | order.total | Minuscolo, parole unite da . |
| Title Case | Order Total | Parole separate da spazi, ognuna con l’iniziale maiuscola |
| Sentence case | Order total | Solo la prima parola con l’iniziale maiuscola |
camelCase è talvolta chiamato lower camel case e PascalCase upper camel case. CONSTANT_CASE è noto anche come screaming snake case.
Lo stile atteso da ogni linguaggio e formato
La maggior parte degli ecosistemi ha da tempo stabilito delle convenzioni, e rispettarle rende il codice più facile da leggere per chi conosce quell’ecosistema:
| Dove | Convenzione abituale |
|---|---|
| JavaScript, TypeScript, Java | camelCase per variabili e funzioni, PascalCase per le classi, CONSTANT_CASE per le costanti fisse |
| Python (PEP 8) | snake_case per funzioni e variabili, PascalCase per le classi, CONSTANT_CASE per le costanti |
| C# | PascalCase per tipi, metodi e membri pubblici; camelCase per variabili locali e parametri |
| Go | PascalCase esporta un nome fuori dal suo package, camelCase lo mantiene privato |
| Ruby, Rust | snake_case per metodi e variabili, PascalCase per i tipi |
| CSS e HTML | kebab-case per proprietà, nomi di classe e attributi data- |
| URL | kebab-case; Google consiglia trattini, non trattini bassi, tra le parole |
| Tabelle e colonne SQL | snake_case, perché molti database uniformano a un solo tipo di lettere i nomi non racchiusi tra virgolette |
| Variabili d’ambiente | CONSTANT_CASE, come DATABASE_URL |
| Chiavi di configurazione | dot.case per le impostazioni annidate, come server.port |
| API JSON | Nessuna regola unica: molte usano camelCase, altre snake_case; segui l’API che stai usando |
Nella maggior parte dei linguaggi di programmazione il kebab-case non si può usare per i nomi di variabile, perché il trattino è letto come segno meno: order-total significa order meno total.
Acronimi e numeri
Gli acronimi sono il punto in cui le convenzioni divergono di più. Una scuola li mantiene in maiuscolo (userID, parseHTML); l’altra li tratta come parole normali (userId, parseHtml). Le guide di stile Java e JavaScript di Google seguono il secondo approccio, che mantiene chiari i confini tra le parole quando gli acronimi si incontrano: XmlHttpRequest si scompone più facilmente di XMLHTTPRequest. Le linee guida .NET di Microsoft scrivono in maiuscolo gli acronimi di due lettere (IOStream) e mettono la maiuscola solo alla prima lettera di quelli più lunghi (HtmlButton). L’API del browser XMLHttpRequest mescola i due approcci, ed è per questo che viene spesso citata come esempio da evitare.
I numeri non hanno maiuscole né minuscole, quindi un convertitore non può sapere se utf8Decoder significa «utf8 decoder» o «utf 8 decoder». I convertitori di solito attaccano il numero alla parola precedente. Scegli una grafia e usala ovunque.
Title Case e Sentence case nei titoli
Nei titoli in inglese, le guide di stile non mettono la maiuscola a ogni parola allo stesso modo. Gli stili AP e Chicago lasciano in minuscolo articoli, congiunzioni e preposizioni brevi tranne che all’inizio o alla fine («The Lord of the Rings») e differiscono nell’elenco preciso. Molte guide per interfacce e documentazione, comprese le guide per la documentazione per sviluppatori di Microsoft e Google, usano il Sentence case («Change your password»), più facile da applicare in modo coerente e meno formale. Anche in italiano i titoli seguono di norma la maiuscola solo sulla prima parola e sui nomi propri.
Il Title Case del convertitore LeedyBox mette la maiuscola a ogni parola. Va bene per etichette e nomi simili a variabili, non per i titoli in stile giornalistico: riporta poi a mano in minuscolo le parole brevi.
Convertire tra stili fa perdere informazioni
Ogni conversione prima scompone il nome in parole, usando maiuscole e separatori come indizi, poi le ricompone nel nuovo stile. Ciò che lo stile di destinazione non può esprimere va perso: parseHTML diventa parse_html, e riconvertito diventa parseHtml. Anche la punteggiatura viene eliminata, quindi «don't» diventa due parole.
Per questo conviene trattare uno stile come riferimento. Se il database usa snake_case e il codice camelCase, converti al confine ogni volta, nella stessa direzione, invece di conservare i nomi in entrambe le forme.
Rinominare le chiavi al confine di un’API
Quando un front-end in camelCase comunica con un back-end in snake_case, la maggior parte delle librerie di serializzazione può mappare i nomi automaticamente, così i dati non vengono mai rinominati a mano. Convertire una tantum un documento JSON, per esempio dati di test o una risposta di esempio, è un’altra cosa, e la modalità «Chiavi JSON» del convertitore lo fa senza toccare i valori.
Attenzione alle collisioni: user_name e userName diventano la stessa chiave in qualsiasi stile, e l’una sovrascrive l’altra. Simboli iniziali come _id o $ref hanno spesso un significato per un database o uno schema, quindi verifica se possono essere rinominati.
Maiuscole e minuscole al di fuori dell’inglese
Le regole su maiuscole e minuscole non sono le stesse in tutte le lingue. La ß tedesca diventa SS in maiuscolo, quindi la parola si allunga. Il turco ha una i con il punto e una ı senza punto: le coppie maiuscole sono i → İ e ı → I, mentre le regole predefinite della maggior parte dei linguaggi di programmazione trasformano i in I. toUpperCase() di JavaScript usa le regole predefinite; toLocaleUpperCase('tr') applica quelle turche. Coreano, cinese e giapponese non hanno affatto maiuscole e minuscole, quindi cambiano solo i separatori tra le parole.
Maiuscole e minuscole possono contare anche nei nomi dei file. Windows e, per impostazione predefinita, macOS trattano Readme.md e README.md come lo stesso file, mentre Linux li tratta come due file. Una ridenominazione che cambia solo le maiuscole può passare inosservata su un sistema e rompere link o import su un altro.
Domande frequenti
È meglio camelCase o snake_case?
In generale nessuno dei due è migliore. Segui la convenzione del linguaggio, del framework o dell’API che usi; la coerenza all’interno di un codice conta più della scelta.
Negli URL meglio i trattini o i trattini bassi?
I trattini. Le indicazioni di Google sugli URL consigliano trattini tra le parole, e slug in kebab-case come /case-converter/ sono la pratica comune sul web.
Perché Git non si accorge che ho cambiato solo le maiuscole del nome di un file?
Su un file system che non distingue maiuscole e minuscole, Git spesso considera il vecchio e il nuovo nome come lo stesso file. Rinomina con git mv, per esempio passando per un nome temporaneo, così la modifica viene registrata per i sistemi che le distinguono.
Come scrivo in camelCase marchi come iPhone o eBay?
Un convertitore spezza le parole sulle maiuscole, quindi nomi del genere diventano parole separate. Nel codice di solito è più chiaro trattare il marchio come una sola parola (iphoneModel) e usare la grafia ufficiale solo nel testo letto dalle persone.