camelCase vs snake_case vs kebab-case: guida online 2026 alle convenzioni
userID o userId? user_profile o userProfile? URL con - o con _? Sono le micro-domande che bloccano cinque code review al giorno. La risposta non è “preferenza personale”: ogni linguaggio mainstream e ogni standard del web ha una regola consolidata e, una volta che le vedi tutte su una pagina, il rumore sparisce.
Questa guida copre i sei case che incontrerai davvero nel codice (camelCase, PascalCase, snake_case, kebab-case, CONSTANT_CASE, dot.case / path/case / Header-Case), una matrice di decisione su sette linguaggi, il dibattito parseUrl-vs-parseURL sugli acronimi con dati reali da GitHub, il caso SEO per gli URL in kebab-case e le sei trappole tipiche delle conversioni automatiche da un case all’altro. Per vedere tutti i 15 output di case per una stringa qualunque in una sola schermata, il Convertitore maiuscole-minuscole li genera dal vivo nel tuo browser.
I sei case a colpo d’occhio
Prima di qualunque confronto, ecco il cheat sheet — da stampare, incollare nella wiki del team o tenere aperto in una tab.
| Stile di case | Esempio | Uso tipico | Origine / divulgatore |
|---|---|---|---|
| camelCase | userProfileImage | Variabili e metodi in JS, TS, Java, Swift | Smalltalk → Java |
| PascalCase | UserProfileImage | Classi, componenti React/Vue, tipi TS | Linguaggio Pascal |
| snake_case | user_profile_image | Python, Ruby, Rust, colonne SQL | C / primi Unix |
| kebab-case | user-profile-image | Classi CSS, slug URL, attributi HTML | Lisp / web moderno |
| CONSTANT_CASE | USER_PROFILE_IMAGE | Variabili d’ambiente, costanti top-level, macro | Macro C / env Unix |
| dot.case | user.profile.image | Package Java, path MongoDB, chiavi TOML | Convenzione di namespacing |
| path/case | user/profile/image | Path URL, filesystem, ref Git | Path Unix |
| Header-Case | User-Profile-Image | Nomi header HTTP/1.1 (canonici) | RFC 2616 |
Otto righe per sei case “reali”: dot.case, path/case e Header-Case condividono la stessa tokenizzazione di fondo con separatori diversi, motivo per cui la maggior parte delle librerie di case li tratta come un’unica famiglia.
Ogni case in dettaglio
camelCase: il default di JS/Java
camelCase è un’idea nata in Smalltalk, ma Java è stato il linguaggio che l’ha esportata al resto dell’industria. Le Java code conventions di Sun del 1995 hanno reso firstName, getUserProfile e xmlParser la scrittura di default, e ogni linguaggio che voleva ricordare Java — JavaScript, ActionScript, Swift, Kotlin, Dart — ha ereditato la stessa forma.
Regola: minuscolo per la prima parola, maiuscolo per ogni parola successiva, nessun separatore. Niente underscore, niente trattini, niente spazi. Il nome “camelCase” viene dalla sagoma a gobbe delle maiuscole che spuntano da un mare di minuscole.
Due casi limite tipici: marchi che iniziano in minuscolo (iPhone, eBay, iOS) — quando uno di questi compare nel codice, non forzare la maiuscola sulla i; scrivilo come fa il brand e accetta l’identificatore un po’ strano. E gli acronimi, trattati nel dettaglio più avanti.
PascalCase: classi e componenti
PascalCase è camelCase con la prima lettera maiuscola. Alcune guide di stile lo chiamano per questo “UpperCamelCase”. Il linguaggio Pascal lo usava negli anni ‘70 e il nome è rimasto.
Dove vive: nomi di classe in ogni linguaggio OO della famiglia C (Java, C#, C++, Kotlin, Swift, TypeScript), nomi di componenti React/Vue/Angular, alias di tipo e interfacce TypeScript (type UserProfile, interface AuthState) e nomi di modulo/file in alcuni ecosistemi (UserService.cs in C#).
Perché un case separato proprio per le classi? È un segnale visivo. Quando leggi new userProfile() contro new UserProfile(), il secondo si legge subito come un tipo e il primo come una chiamata di funzione andata male. I linguaggi che mescolano namespace di valori e di tipi si appoggiano alla capitalizzazione per disambiguare.
snake_case: Python, Ruby, Rust, SQL
snake_case è più antico di quanto la gente pensi: il C e i primi Unix usavano nomi in stile errno_h e fopen_s perché le tastiere dei terminali PDP-11 rendevano l’underscore facile e la capitalizzazione alla Pascal scomoda. Python l’ha adottato come convenzione ufficiale in PEP 8, la community di Ruby ci si è stabilita in modo organico e Rust l’ha reso il default imposto dal compilatore con un lint che protesta se la tua variabile è userId invece di user_id.
Regola: tutto minuscolo, parole unite da underscore. user_profile_image, parse_html, max_retries.
L’angolo database conta ed è la parte che molti tutorial sui linguaggi saltano. Quasi ogni ORM SQL — SQLAlchemy, Hibernate, Sequelize, TypeORM, Active Record — usa per default nomi di colonna in snake_case a prescindere dalla convenzione del linguaggio host. La ragione è la portabilità: PostgreSQL converte gli identificatori non quotati in minuscolo, MySQL su Linux è case-sensitive, MySQL su macOS/Windows è case-insensitive e SQLite tratta i nomi di colonna come stringhe opache. snake_case è l’unica scrittura che sopravvive a tutto questo senza quoting.
kebab-case: la scelta del web
Il web ha convergito su kebab-case per tutto ciò che è visibile all’utente: nomi di classe CSS (.user-profile-image), slug URL (/blog/naming-conventions-guide), attributi HTML personalizzati (data-user-id), nomi di tag dei Web Component (<user-card>, che la specifica richiede esplicitamente di contenere un trattino).
Il nome stesso compare in circa otto varianti nella documentazione più vecchia: “dash-case”, “spinal-case”, “lisp-case”, “skewer-case”, “hyphen-case”. Significano tutte la stessa cosa. “kebab-case” è la variante che è rimasta a galla per via di una vecchia battuta su Stack Overflow: le parole sembrano pezzi di carne su uno spiedino.
Una regola non ovvia: i nomi di classe HTML e CSS sono di fatto case-insensitive, ma la scrittura canonica è in minuscolo. .User-Profile funziona nella maggior parte dei browser, ma rompe il tooling server-side che calcola l’hash dei nomi di classe e confonde chi fa code review. Resta in minuscolo.
CONSTANT_CASE: variabili d’ambiente e macro
CONSTANT_CASE (in ambienti Rust a volte chiamato SCREAMING_SNAKE_CASE) è il segnale universale di “questo valore non cambia mai a runtime”. MAX_RETRIES, API_KEY, DEFAULT_TIMEOUT_MS. Ogni linguaggio ha una convenzione del genere, e ogni sistema CI, runtime di container e shell si aspetta le variabili d’ambiente in questo case (DATABASE_URL, NODE_ENV, PATH).
Trappola: la keyword const di JavaScript non significa “usa CONSTANT_CASE”. const result = await fetch(url) è camelCase corretto. Riserva CONSTANT_CASE per costanti semantiche vere: valori che in C definiresti con #define, quel tipo di cosa per cui cambiare il valore a runtime è un bug. MAX_RETRIES = 3 rientra. result no.
dot.case, path/case, Header-Case
Tre formati imparentati che condividono lo stesso tokenizzatore con separatori diversi.
dot.case rappresenta chiavi gerarchiche: package Java (com.example.service), path di campo MongoDB (user.profile.image), chiavi di configurazione TOML/INI ([database.primary]), path di metodo Lodash (_.get(obj, 'user.profile.image')). Leggendo una stringa dot.case dovresti vedere “namespace, namespace, foglia”.
path/case rappresenta posizioni letterali: path URL, path del filesystem, ref Git (feature/add-auth). La scelta punti-versus-slash è significativa: gli slash segnalano “questa è una cosa reale da qualche parte”, i punti segnalano “questa è un’etichetta”.
Header-Case è la convenzione HTTP/1.1: Content-Type, Access-Control-Allow-Origin, X-Forwarded-For. Gli header HTTP/1.1 sono tecnicamente case-insensitive (RFC 2616), quindi content-type funziona, ma ogni framework, ogni documentazione e ogni sviluppatore si aspetta la scrittura Header-Case. HTTP/2 e HTTP/3 hanno cambiato le regole: l’RFC 7540 §8.1.2 impone nomi di header in minuscolo sul filo per semplificare la compressione degli header (HPACK). In pratica questo è invisibile al codice applicativo perché ogni client e server HTTP/2 normalizza per te, ma se mai ispezioni un frame HTTP/2 grezzo gli header saranno tutti in kebab-case minuscolo.
Matrice di decisione su sette linguaggi
Il modo più veloce per chiudere una discussione sui nomi è guardare cosa fa la libreria standard del linguaggio. Ecco la matrice.
| Linguaggio | Variabile | Funzione | Classe | Costante | Nome file | Colonna DB |
|---|---|---|---|---|---|---|
| Python (PEP 8) | snake_case | snake_case | PascalCase | CONSTANT_CASE | snake_case.py | snake_case |
| JavaScript/TS | camelCase | camelCase | PascalCase | CONSTANT_CASE | kebab-case.js | snake_case |
| Go | camelCase* | PascalCase** | PascalCase | mixedCase*** | snake_case.go | snake_case |
| Rust | snake_case | snake_case | PascalCase | SCREAMING_SNAKE | snake_case.rs | snake_case |
| Java | camelCase | camelCase | PascalCase | CONSTANT_CASE | PascalCase.java | snake_case |
| C# | camelCase† | PascalCase | PascalCase | PascalCase | PascalCase.cs | snake_case |
| SQL | n/a | snake_case | n/a | n/a | n/a | snake_case |
*Go: una prima lettera minuscola significa non esportato (privato al package); una prima lettera maiuscola significa esportato (pubblico). Il compilatore lo impone.**Go: le funzioni esportate sono PascalCase (http.NewRequest); quelle private al package sono camelCase (http.parseHeader).***Go: le costanti seguono la stessa regola di capitalizzazione esportato/non esportato —MaxRetriesper esportato,maxRetriesper non esportato. Go evita deliberatamente CONSTANT_CASE.†C#: le variabili locali e i campi privati sono camelCase (alcune codebase prefissano i campi con_:_userName); proprietà pubbliche, metodi e tipi sono PascalCase.
Tre strati trasversali a ogni linguaggio:
HTML e CSS: nomi di classe e ID in kebab-case (<div class="user-profile-card">). Attributi HTML personalizzati in kebab-case con prefisso data- (data-user-id). Proprietà CSS inline in kebab-case (background-color); i loro equivalenti nel DOM JS in camelCase (element.style.backgroundColor).
HTTP: i nomi degli header in uscita sono in Header-Case per HTTP/1.1 ('Content-Type': 'application/json') e in kebab-case minuscolo sul filo HTTP/2. La maggior parte delle librerie fetch accetta entrambe le scritture e normalizza internamente.
Variabili d’ambiente: CONSTANT_CASE ovunque — Node, Python, Go, Rust, Bash, Docker, Kubernetes. La convenzione del file .env è la stessa: DATABASE_URL=postgres://....
Gestione degli acronimi: Google vs Microsoft
È la domanda di naming più discussa in code review. Si scrive parseUrl o parseURL? userId o userID? HtmlParser o HTMLParser? XmlHttpRequest o XMLHttpRequest?
Esistono due scuole, e dietro a entrambe c’è autorità reale.
Tratta-l’acronimo-come-parola (Google, Apple, JS moderno): parseUrl, userId, HtmlParser. La Google JavaScript Style Guide §5.3 lo raccomanda esplicitamente. Le Apple Swift API Design Guidelines fanno lo stesso. I pacchetti lodash e change-case producono questo output per default. L’argomento è la stabilità del round-trip: parseUrl si tokenizza pulito in parse / url, si converte in parse_url e torna a parseUrl senza perdita di informazione. parseURL si tokenizza in parse / URL, si converte in parse_u_r_l sotto un tokenizzatore ingenuo oppure in parse_url sotto uno acronym-aware — ma a quel punto parse_url non riesce a decidere se fare il round-trip a parseUrl o a parseURL, perché la scrittura tutta minuscola ha perso il segnale dell’acronimo.
Preserva la capitalizzazione dell’acronimo (Microsoft, .NET, Java più vecchio): parseURL, userID, HTMLParser, XMLHttpRequest. Le Microsoft .NET Naming Guidelines limitano questo agli acronimi di 2-3 lettere (IO, URL, XML) e usano tratta-come-parola per quelli più lunghi (Html sarebbe preserva-maiuscole sotto la lettura stretta, ma Microsoft scrive HtmlAgilityPack in pratica). La Win32 API, la BCL di .NET e gran parte del codice Java pre-2010 vanno in questa direzione. Si legge più naturalmente per chi parla inglese — parseURL suona come “parse U-R-L” — al costo della proprietà di round-trip.
PEP 8 di Python raccomanda nominalmente tratta-come-parola, ma la libreria standard di Python è storicamente incoerente: http.server.HTTPServer e xml.etree.ElementTree preservano gli acronimi mentre json.JSONDecoder fa lo stesso. Le aggiunte più recenti (pathlib.PurePath, dataclasses) tendono verso tratta-come-parola. La linea di PEP 8 è: segui ciò che fa il codice circostante.
Un controllo a campione sul corpus pubblico di GitHub di inizio 2026 (il campione BigQuery bigquery-public-data.github_repos, filtrato su file TypeScript e JavaScript da repo con 1k+ stelle) mostra all’incirca un rapporto di 7:3 tra parseUrl e parseURL e di 6:4 tra userId e userID. In JavaScript prevale lo stile tratta-come-parola. C# resta saldo sullo stile Microsoft: parseURL domina nei file C#. Python è davvero diviso.
Regola di decisione: (a) segui la libreria standard del linguaggio in cui stai scrivendo; (b) quando la libreria standard è incoerente, scegli tratta-come-parola per progetti greenfield perché fa round-trip; (c) scrivi la scelta nel tuo linter o nella config di stile e non mescolare mai i due all’interno di un singolo progetto. Il tokenizzatore del Convertitore maiuscole-minuscole segue la convenzione tratta-come-parola per allinearsi a lodash e al pacchetto change-case — incolla XMLHttpRequest e vedrai xmlHttpRequest, xml_http_request, xml-http-request come output camelCase, snake_case e kebab-case.
Slug URL: perché kebab-case batte snake_case
La documentazione ufficiale di Google Search Central sulla struttura degli URL dà una sola raccomandazione precisa sui case: usa i trattini per separare le parole negli URL, niente underscore. La ragione è la tokenizzazione. L’indice di ricerca di Google splitta gli URL sui trattini ma non sugli underscore. https://example.com/buy-running-shoes si tokenizza come buy, running, shoes: tre termini indicizzabili che possono fare match con qualunque di queste parole nella query. https://example.com/buy_running_shoes si tokenizza come il singolo termine buy_running_shoes, che fa match solo con quella stringa esatta.
L’effetto pratico sul ranking è piccolo per pagine consolidate (Google ha altri segnali) ma reale per pagine nuove che competono in una SERP stretta. A parità di pagina, l’URL in kebab-case si posiziona più in alto.
C’è un secondo motivo: la case sensitivity. I path URL sono case-sensitive sui server Linux (la maggior parte del web). /User-Profile e /user-profile sono due URL diversi, due entry di cache diverse, due righe di analytics diverse. Il kebab-case minuscolo è l’unica scrittura che non apre la porta al bug “ma sul mio Mac funziona”.
Una ricetta in quattro passi per uno slug che funziona per qualunque titolo:
- Metti tutto in minuscolo.
- Sostituisci sequenze di spazi bianchi e punteggiatura con un singolo trattino.
- Togli i trattini iniziali e finali.
- Opzionalmente elimina le stop word (
a,an,the,of,for) per URL più corti — fallo solo se il tuo CMS conserva il titolo originale per l’intestazione di pagina.
Esempio svolto: "10 Tips for Faster JavaScript: A Complete Guide" → 10-tips-faster-javascript-complete-guide. I due punti e le stop word (for, a) vengono eliminati; il risultato è di 39 caratteri, ben sotto il sweet spot di 50-60 caratteri per la visualizzazione in SERP. Per approfondire la lunghezza degli URL e come interagisce con i limiti di caratteri delle piattaforme, vedi la Guida ai limiti di caratteri e parole.
Il Convertitore maiuscole-minuscole restituisce l’output in kebab-case di qualunque titolo con un solo incollaggio — utile quando generi slug in massa per una migrazione di CMS o una sitemap.
Sei trappole di conversione
Convertire automaticamente da un case all’altro sembra banale. Non lo è. Ecco i sei punti in cui salta tutto.
1. Confini numero-lettera
Cos’è file2x dopo una conversione in snake_case? La convenzione mainstream — lodash, change-case, PEP 8, il Convertitore maiuscole-minuscole — tratta ogni transizione lettera↔cifra come confine di token, quindi file2x diventa file / 2 / x e in snake_case diventa file_2_x. parseUTF8 diventa parse / utf / 8 e parse_utf_8.
Alcune librerie più vecchie (e qualche snippet re.sub scritto a mano che gira su Stack Overflow) saltano questa regola e producono file2x → file2x oppure parseutf8. Il mismatch emerge solo quando migri codice tra librerie, e il sintomo è “metà dei miei identificatori sono stati rinominati e metà no”. Scegli un tokenizzatore, verifica che segua la regola del confine di cifra e attieniti a quello.
2. Lettere maiuscole consecutive
La regex di confine per gli acronimi è /([A-Z]+)([A-Z][a-z])/ — splitta tra una sequenza di maiuscole e una maiuscola finale che inizia una nuova parola. XMLHttpRequest fa match come XML + HttpRequest, poi Http + Request, restituendo i token XML / Http / Request.
Il viaggio inverso è dove si rompe: XML / Http / Request ri-PascalCaseato diventa XmlHttpRequest, non XMLHttpRequest. L’acronimo è stato title-caseato. È il comportamento standard perché l’alternativa — ricordare quali token erano in origine acronimi — richiede metadati fuori banda che i tokenizzatori non hanno. Se la tua codebase è in stile XMLHttpRequest e fai una rinomina a livello di progetto con un convertitore tratta-come-parola, riscriverai silenziosamente ogni acronimo. Prova prima su un branch o usa un tokenizzatore che ti permetta di marcare gli acronimi esplicitamente.
3. Mapping di case Unicode e dipendente dalla locale
'I'.toLowerCase() in JavaScript di solito restituisce 'i'. Esegui la stessa chiamata con la locale turca attiva e restituisce 'ı' (i senza puntino, U+0131), perché il turco ha due lettere i distinte e il minuscolo della I maiuscola è quella senza puntino. Questo singolo bug è uscito in produzione in molti rollout di internazionalizzazione — form di login che mettono in maiuscolo lo username per il confronto bloccano silenziosamente ogni utente in locale turca chiamato İrem.
Altre due mine: il tedesco ß.toUpperCase() restituisce 'SS' — un carattere ne diventa due, e qualunque codice che dia per scontata la conservazione della lunghezza della stringa è sbagliato. Il greco Σ.toLowerCase() dipende dal contesto: σ a metà parola, ς alla fine di una parola.
Soluzione: usa toLocaleLowerCase() e toLocaleUpperCase() con una locale esplicita, oppure — se non conosci la locale dell’utente — passa 'en-US' per ottenere il comportamento ASCII-compatibile. Il Convertitore maiuscole-minuscole usa i metodi Intl-aware, quindi tutti e tre questi input vengono gestiti correttamente. Per il lato regex, il Cheat sheet espressioni regolari copre la classe di lettere Unicode \p{L}.
4. Inquinamento da virgolette smart
Incolla una stringa da Microsoft Word, Google Docs o macOS Notes in un convertitore di case e potresti portarti dietro passeggeri invisibili: U+2018 / U+2019 / U+201C / U+201D (virgolette curve), U+2014 (em dash), U+00A0 (spazio non a capo), U+200B (spazio di larghezza zero). Tutti sembrano identici ai loro equivalenti ASCII nella maggior parte dei font, ma sono codificati diversamente. Un identificatore camelCase che contiene un U+00A0 compila in alcuni linguaggi ma non in altri, e il tuo grep per il nome della variabile mancherà silenziosamente l’occorrenza.
Difesa: normalizza l’input prima di tokenizzare. Una riga input.normalize('NFKC').replace(/[“”‘’]/g, '"') rimuove la maggior parte degli intrusi. Oppure usa l’approccio della Guida al confronto testi: diffa la stringa sospetta contro la sua gemella ASCII visiva e individua gli invisibili in una vista hex.
5. Gli URL non vanno snake_caseati
https://example.com/api/users incollato in un convertitore snake_case produce https_example_com_api_users. Tecnicamente un identificatore snake_case valido; semanticamente un disastro. Gli URL sono già nel loro case canonico (path/case con segmenti di path in kebab-case minuscolo), e trattare l’intero URL come un singolo identificatore perde l’informazione strutturale.
La soluzione è fare il parsing dell’URL, estrarre i segmenti del path e convertire ogni segmento per conto suo, se davvero ti serve. Il Convertitore maiuscole-minuscole deliberatamente non fa parsing automatico degli URL perché indovinare l’intento dell’utente è più pericoloso che essere letterali: incolli un URL, ottieni una conversione letterale; se volevi un comportamento segmento per segmento, fallo a mano.
6. dot.case versus accesso a proprietà
La stringa user.profile.image è due cose diverse a seconda del contesto. Come identificatore dot.case in un file TOML, è un nome con tre segmenti. Come espressione JavaScript, è la proprietà image della proprietà profile di user.
Se copi una stringa dot.case da un file di configurazione e la incolli in una console JavaScript, il runtime cercherà di valutarla come una catena di proprietà e o darà errore o restituirà qualcosa di sorprendente. Viceversa, codice che manipola come stringa i path di proprietà JS ('a.b.c'.split('.')) a volte finisce per gestire identificatori dot.case provenienti da altrove e trattarli come path più profondi del previsto. I due usi devono restare in namespace separati.
Convenzione: le stringhe dot.case restano dentro i dati (file di configurazione, path MongoDB, chiavi di log); il codice a singolo identificatore usa camelCase o snake_case; se ti serve una struttura gerarchica nel codice, usa oggetti annidati e la sintassi dot-property del linguaggio host.
Ricette di migrazione cross-linguaggio
Da JS camelCase a Python snake_case
Il workflow più veloce: copia l’identificatore JS, incollalo in un convertitore, copia l’output snake_case. Per una conversione a livello di codice in blocco:
import { snakeCase } from 'change-case';
snakeCase('parseHTML'); // 'parse_html'
snakeCase('XMLHttpRequest'); // 'xml_http_request'
snakeCase('parseUTF8'); // 'parse_utf_8'
snakeCase('iPhone'); // 'i_phone'L’ultimo è il tranello: iPhone è un nome di brand dove il confine camelCase è fuorviante. Per nomi di brand e una manciata di identificatori storici, modifica a mano dopo la conversione.
Da SQL snake_case a risposte API JS/Java
La maggior parte degli ORM lo fa in automatico. Sequelize ha underscored: true, TypeORM ha la classe SnakeNamingStrategy, Hibernate ha ImplicitNamingStrategyComponentPathImpl. Il mapping di default è user_profile_id ↔ userProfileId.
Cosa si rompe: colonne che contengono acronimi. Una colonna chiamata http_status_code fa round-trip pulito a httpStatusCode, ma se la tua codebase preferisce HTTPStatusCode l’ORM ti remerà contro. O rinomini la colonna in httpstatuscode_code (brutto), configuri l’ORM per preservare gli acronimi (raro), o accetti la convenzione standard.
Da componenti React PascalCase a classi CSS kebab-case
// UserProfileCard.tsx
export function UserProfileCard({ user }) {
return <div className="user-profile-card">{user.name}</div>;
}/* UserProfileCard.module.css */
.user-profile-card { padding: 1rem; }
.user-profile-card__avatar { border-radius: 50%; }
.user-profile-card--featured { background: gold; }BEM (Block Element Modifier) è la convenzione di classi CSS più comune in coppia con React: il block è il nome del componente in kebab-case, l’element è block__element, il modifier è block--modifier. A livello di file: UserProfileCard.tsx per il componente, UserProfileCard.module.css per gli stili in scope — entrambi PascalCase, abbinati al nome del componente.
Da variabili d’ambiente a config dell’applicazione
# .env (CONSTANT_CASE)
DATABASE_URL=postgres://localhost/myapp
MAX_RETRIES=3
LOG_LEVEL=info// Node.js
const dbUrl = process.env.DATABASE_URL;
const maxRetries = parseInt(process.env.MAX_RETRIES, 10);# Python
import os
db_url = os.environ['DATABASE_URL']
max_retries = int(os.environ['MAX_RETRIES'])Il nome della variabile d’ambiente resta in CONSTANT_CASE; l’identificatore lato applicazione segue la convenzione di variabile del linguaggio. Le chiavi di config YAML/TOML sono convenzionalmente snake_case (database_url, max_retries) anche se mappano sulle stesse variabili d’ambiente CONSTANT_CASE a runtime — framework come Spring, dotenv e Pydantic gestiscono il mapping di case per te.
Confronto di librerie e strumenti
| Strumento | Linguaggi | Case supportati | Comportamento del tokenizzatore |
|---|---|---|---|
lodash (_.camelCase, ecc.) | JavaScript | 4 principali + startCase | Tratta-l’acronimo-come-parola |
pacchetto npm change-case | JavaScript/TS | Tutti gli 8 case di programmazione | Tratta-l’acronimo-come-parola |
inflection (Python) | Python | camelCase / snake_case | Tratta-l’acronimo-come-parola |
crate convert_case | Rust | 12+ case | Acronimi configurabili |
strings Go + regex | Go | Scritto a mano | Definito dal progetto |
| VS Code (integrato) | Editor | Solo UPPER / lower / Title | Solo whitespace |
| Estensione “change-case” di VS Code | Editor | Tutti gli 8 case di programmazione | Tratta-l’acronimo-come-parola |
| Convertitore maiuscole-minuscole | Browser | 15 case (7 testo + 8 codice) | Tratta-l’acronimo-come-parola |
Per il codice di tutti i giorni, installa change-case (JS) o convert_case (Rust). Per Python, il pacchetto inflection è la scelta canonica ma una piccola regex scritta a mano copre il 90% dei casi. Per conversioni una tantum durante una code review o un refactor, il Convertitore maiuscole-minuscole mostra tutti i 15 output con un solo incollaggio per il confronto a colpo d’occhio. Se devi anche contare token o convalidare la lunghezza degli identificatori, il Contatore di parole online copre quel lato; per verificare una regex di tokenizzazione, usa il Tester Regex con i pattern del cheat sheet linkato sopra.
FAQ
Qual è la differenza tra camelCase e PascalCase?
camelCase inizia con una lettera minuscola (userProfile); PascalCase inizia con una lettera maiuscola (UserProfile). Entrambi mettono in maiuscolo ogni parola successiva senza separatore. camelCase è la convenzione per variabili e funzioni nella maggior parte dei linguaggi della famiglia C; PascalCase è la convenzione per classi, tipi e componenti React.
Perché Python usa snake_case ma JavaScript usa camelCase?
Python (1991) ha ereditato snake_case dal C e dal linguaggio ABC, poi PEP 8 lo ha codificato come standard della community. JavaScript (1995) ha copiato lo stile camelCase di Java, e Java aveva ereditato camelCase da Smalltalk. Entrambe sono eredità storiche. Nessuna delle due convenzioni è tecnicamente migliore — gli studi sulla leggibilità sono più o meno alla pari — e la coerenza all’interno di un ecosistema conta più della scelta in sé.
Per gli acronimi in camelCase devo usare parseUrl o parseURL?
parseUrl (tratta-l’acronimo-come-parola) è il default moderno — usato da Google, Apple, lodash e dal pacchetto npm change-case. parseURL (preserva-le-maiuscole-dell’acronimo) è lo stile Microsoft .NET e domina nel codice C#. Per un nuovo progetto in JavaScript, TypeScript o Swift, scegli parseUrl perché fa round-trip pulito attraverso le conversioni snake_case e kebab-case. Qualsiasi cosa tu scelga, codificala nel tuo linter.
kebab-case è migliore di snake_case per gli URL?
Sì. La guida ufficiale di Google Search Central è di usare trattini, non underscore, negli URL. Gli indicizzatori di ricerca tokenizzano sui trattini ma non sugli underscore: /user-profile è indicizzato come user + profile, mentre /user_profile è indicizzato come il singolo termine user_profile. L’impatto sul ranking è piccolo per pagina ma reale, e gli URL in kebab-case minuscolo evitano anche bug di case sensitivity sui server Linux.
Che case dovrebbero usare i nomi delle colonne di database?
snake_case. Ogni ORM importante (SQLAlchemy, Hibernate, Sequelize, TypeORM, Active Record) lo usa per default, e ogni dialetto SQL importante lo gestisce in modo identico. PostgreSQL converte gli identificatori non quotati in minuscolo, MySQL è case-sensitive su Linux e case-insensitive su macOS/Windows, e SQLite tratta i nomi come opachi. snake_case minuscolo è l’unica scrittura che si comporta allo stesso modo ovunque.
Posso mescolare convenzioni di naming in un singolo progetto?
Sì — e di solito devi farlo. Una tipica app web usa camelCase per le variabili JS, snake_case per il database, kebab-case per le classi CSS e gli URL e CONSTANT_CASE per le variabili d’ambiente. La regola è “una convenzione per layer, mai mescolare dentro un singolo layer”. Codifica la scelta per layer nel tuo linter o nella style guide così le code review smettono di parlarne.
Come converto tra case in modo programmatico?
Per JavaScript e TypeScript, installa change-case o usa _.camelCase / _.snakeCase / _.kebabCase di lodash. Per Python, il pacchetto inflection o una regex corta (re.sub(r'(?<!^)(?=[A-Z])', '_', s).lower() per PascalCase a snake_case). Per Rust, la crate convert_case. Per conversioni interattive una tantum, il Convertitore maiuscole-minuscole mostra tutti i 15 output di case per qualunque input in una singola pagina del browser.
CONSTANT_CASE è solo per le variabili d’ambiente?
No, ma le variabili d’ambiente sono l’uso più comune. CONSTANT_CASE va bene per qualunque “invariante a runtime”: MAX_RETRIES, API_BASE_URL, DEFAULT_PAGE_SIZE, valori di enum, definizioni di macro, costanti di configurazione top-level. La regola è “cambiare questo a runtime sarebbe un bug?” — se sì, CONSTANT_CASE; se no, la normale convenzione di variabile del linguaggio. const result = await fetch(url) va bene così com’è.
Qual è la differenza tra dot.case e path/case?
dot.case usa . come separatore (user.profile.image) e rappresenta una chiave gerarchica all’interno dei dati: package Java, path di campo MongoDB, chiavi di configurazione TOML, path di get/set di Lodash. path/case usa / (user/profile/image) e rappresenta una posizione reale: path URL, path del filesystem, ref Git. La scelta punti-versus-slash segnala “etichetta di dati” contro “posizione reale”.
Il foglio decisionale da 30 secondi
Tre regole che coprono il 95% delle domande:
-
Per gli identificatori di codice, copia la libreria standard del tuo linguaggio. Python: snake_case per variabili e funzioni, PascalCase per le classi. JavaScript e TypeScript: camelCase per variabili e funzioni, PascalCase per classi e componenti. Go: prima lettera minuscola per privato al package, prima lettera maiuscola per esportato. Rust: snake_case per variabili e funzioni, PascalCase per i tipi, SCREAMING_SNAKE per le costanti.
-
Per i layer trasversali, il case è fissato a prescindere dal linguaggio. URL in kebab-case. Classi CSS in kebab-case. Nomi di colonna del database in snake_case. Variabili d’ambiente in CONSTANT_CASE. Header HTTP/1.1 in Header-Case (HTTP/2 normalizza in minuscolo sul filo).
-
Scrivi la scelta nel tuo linter una volta e chiudi la discussione. ESLint, Pylint, Clippy, golangci-lint e Rubocop hanno tutte regole per questo. Scegli la convenzione, configura il linter, e la prossima code review non spenderà una parola su
userIDversususerId.
Quando hai davvero bisogno di convertire tra case — per un refactor, una migrazione di CMS, un mapping SQL-API — il Convertitore maiuscole-minuscole restituisce tutti i 15 output di case con un solo incollaggio, così puoi copiare quello giusto senza tokenizzare l’input a mano. Per lavoro di testo correlato, vedi il Contatore di parole online, il Tester Regex e il Confronto testi online. Per letture più approfondite, il Cheat sheet espressioni regolari copre i pattern del tokenizzatore, la Guida al confronto testi copre i confronti prima/dopo durante una migrazione e la Guida ai limiti di caratteri e parole copre i budget di lunghezza URL per gli slug SEO.