← Blog · 19 aprile 2026 · Team ConvertCaseHQ · 7 min di lettura

camelCase, snake_case, kebab-case: la guida rapida per sviluppatori

Ecco la versione breve. Tipi e classi usano PascalCase in quasi tutti i linguaggi. Variabili e funzioni usano camelCase in JavaScript, Java, C#, Kotlin e Swift, ma snake_case in Python, Ruby e Rust. Le costanti usano SCREAMING_SNAKE_CASE nella maggior parte dei linguaggi, con le eccezioni di Go, Swift, C# e del C++ in stile Google. Tutto ciò che finisce in un URL, in un file CSS o nel nome di un pacchetto è di solito in kebab-case minuscolo, e le variabili d'ambiente sono in maiuscolo con i trattini bassi.

Questo è lo schema. I dettagli sono il punto in cui nascono le discussioni nelle code review, quindi questa guida rapida si attiene a ciò che dicono davvero la guida di stile ufficiale o quella più diffusa di ciascun linguaggio, e indica la fonte per ognuno.

camelCase, snake_case, kebab-case: i cinque stili e gli altri nomi con cui li trovi

• camelCase (orderTotal): la prima parola è in minuscolo, ogni parola successiva ha l'iniziale maiuscola. Si chiama anche lowerCamelCase; PEP 8 lo chiama mixedCase.
• PascalCase (OrderTotal): ogni parola ha l'iniziale maiuscola. Si chiama anche UpperCamelCase, CapWords (PEP 8) o StudlyCaps (PSR-1 di PHP).
• snake_case (order_total): parole in minuscolo unite da trattini bassi.
• SCREAMING_SNAKE_CASE (ORDER_TOTAL): parole in maiuscolo unite da trattini bassi. La guida JavaScript di Google lo chiama CONSTANT_CASE, quella per Java UPPER_SNAKE_CASE.
• kebab-case (order-total): parole in minuscolo unite da trattini. Nella maggior parte dei linguaggi non si può usare per gli identificatori, perché il trattino è il segno meno.

Per passare un nome da uno stile all'altro, incollalo nel nostro convertitore di maiuscole/minuscole. Divide il testo in corrispondenza di spazi, trattini bassi, trattini e maiuscole già presenti, così order_total, order-total e OrderTotal si convertono senza problemi l'uno nell'altro. Però fai un nome alla volta: tutto ciò che c'è nel riquadro viene trattato come un unico identificatore.

Guida rapida: le convenzioni di nomi linguaggio per linguaggio

Un paio di righe richiedono una nota. In Go la prima lettera non è affatto una scelta di stile: è la regola di visibilità. Area è esportata dal suo pacchetto e area no, e a farlo rispettare è il compilatore. Il C++ non ha una convenzione valida per tutto il linguaggio; la libreria standard stessa usa snake_case (std::unordered_map, push_back), quindi considera la riga di Google come un'opzione ben documentata, non come la regola.

Rust è insolitamente rigido sullo stile. Il compilatore avvisa già di serie: se scrivi fn GetUser() o struct user_account, rustc ti suggerisce get_user e UserAccount prima ancora che tu abbia usato un linter.

Nomi di file, moduli e pacchetti

• Java: una classe pubblica di primo livello deve stare in un file che ha esattamente il suo nome, maiuscole comprese. OrderService va in OrderService.java, e javac rifiuta qualsiasi altra cosa.
• Kotlin: un file che contiene una sola classe prende il nome di quella classe. Gli altri file hanno un nome descrittivo in UpperCamelCase, come ProcessDeclarations.kt.
• Python: i moduli hanno nomi brevi, tutti in minuscolo, con trattini bassi se aiutano la leggibilità. Anche i pacchetti dovrebbero avere nomi brevi in minuscolo, e PEP 8 sconsiglia di usarvi i trattini bassi.
• Ruby: file in snake_case che prendono il nome della classe che contengono, quindi HelloWorld sta in hello_world.rb.
• Go: i nomi dei pacchetti sono parole singole in minuscolo, senza trattini bassi né mixedCaps: base64, non encoding_base64 né encodingBase64.
• JavaScript e TypeScript: nessuna regola unica. La guida JavaScript di Google vuole nomi di file tutti in minuscolo con trattini bassi o trattini, e la sua guida TypeScript usa snake_case. La guida di Airbnb dice che il nome di un file deve corrispondere al suo export predefinito, quindi una classe CheckBox sta in CheckBox.js. Scegline una per progetto e mettila per iscritto.
• Pacchetti npm: i nomi dei nuovi pacchetti non possono contenere lettere maiuscole.

Oltre il codice sorgente: variabili d'ambiente, CSS, HTML, URL, JSON e SQL

Una particolarità sulle variabili d'ambiente: POSIX dice che le utility standard usano nomi in maiuscolo e riserva alle applicazioni i nomi che contengono lettere minuscole, quindi un nome in minuscolo non può mai entrare in conflitto con uno standard. Il maiuscolo resta comunque l'abitudine consolidata, perciò noi lo manterremmo e, per evitare i conflitti, aggiungeremmo un prefisso distintivo (MYAPP_TIMEOUT).

Le righe su CSS e SQL hanno ciascuna un articolo dedicato: per i nomi delle classi vedi convenzioni di nomi in CSS e BEM, mentre le convenzioni di nomi in SQL spiegano perché i database ti spingono verso il minuscolo.

Le sigle: dove le guide di stile non sono d'accordo

Tutte le guide concordano su userName. Si dividono su userID. Le guide Google per JavaScript e Java scrivono le sigle in minuscolo come parole normali (xmlHttpRequest, customerId). Go lascia ogni sigla tutta in maiuscolo o tutta in minuscolo (ServeHTTP, appID). Le linee guida .NET di Microsoft mettono in maiuscolo entrambe le lettere di una sigla di due lettere (IOStream) ma solo la prima lettera in quelle più lunghe (HtmlTag). Rust le tratta come parole (Uuid), e PEP 8 preferisce HTTPServerError a HttpServerError. Mettiamo a confronto le varie opzioni in camelCase e PascalCase.

Come scegliere quando hai dei dubbi

1. Controlla se è la piattaforma a decidere per te. I nomi delle proprietà CSS, i nomi dei file Java, i nomi esportati di Go e i nomi dei componenti React (che devono iniziare con la maiuscola) non sono scelte di stile.
2. Segui la guida ufficiale del linguaggio. Il codice nuovo dovrebbe somigliare alla libreria standard accanto a cui sta.
3. Adegua il codice al progetto esistente. PEP 8 lo dice chiaro e tondo: la coerenza all'interno di un progetto conta più della coerenza con la guida di stile.
4. Lascia che se ne ricordi un linter. La regola camelcase di ESLint, le regole N di Ruff per Python e gli avvisi integrati di rustc intercettano le sviste prima che debba farlo chi revisiona il codice.
5. Converti una volta sola, al confine. Quando il JSON in snake_case incontra JavaScript in camelCase, rinomina le chiavi in un solo livello di serializzazione invece di lasciare che entrambi gli stili si diffondano in tutto il codice.