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

camelCase e PascalCase: qual è la differenza?

L'unica differenza tra camelCase e PascalCase è la prima lettera. camelCase inizia in minuscolo e mette la maiuscola a ogni parola successiva (userName, parseResponse). PascalCase mette la maiuscola a ogni parola, compresa la prima (UserName, ResponseParser). Per convenzione, PascalCase indica i tipi (classi, interfacce, enum, componenti React) e camelCase i valori e le azioni (variabili, funzioni, metodi, proprietà).

Quella sola maiuscola porta più informazioni di quanto sembri. Qui sotto trovi cosa segnala, i linguaggi in cui è un obbligo e non solo buona educazione, e la parte su cui nessuno è d'accordo: le sigle.

camelCase e PascalCase a colpo d'occhio

Fai attenzione ai termini quando leggi le guide di stile. Molti dicono “camel case” per entrambi gli stili, e PEP 8 elenca addirittura CamelCase come altro nome di CapWords, il termine che usa per PascalCase. Se il senso di una guida non è chiaro, guarda i suoi esempi.

Perché la prima lettera conta: tipi e valori

La convenzione ti permette di leggere il codice senza dover cercare nulla. In const invoice = new Invoice(order) capisci al volo che Invoice è ciò che costruisci e invoice è ciò che ottieni. Le firme TypeScript funzionano allo stesso modo: in function total(order: Order): Money, il nome in minuscolo è il valore e quelli con la maiuscola sono tipi.

Permette anche di usare la stessa parola per un tipo e per un valore senza conflitti, cosa che succede di continuo: user: User, config: Config, request: Request. In un linguaggio che distingue tra maiuscole e minuscole sono identificatori diversi, e la maiuscola dice a chi legge quale è quale.

Dove è il linguaggio a imporla

In JavaScript, Java, C# e Python, la maiuscola nel nome di una classe è solo una convenzione. Niente ti impedisce di scrivere class invoice. In JavaScript puoi trasformare la convenzione in un controllo con la regola new-cap di ESLint: per impostazione predefinita segnala new invoice(), e segnala anche la chiamata senza new di una funzione con la maiuscola come Invoice(), che di solito è un bug. Alcuni linguaggi e framework vanno oltre e integrano la regola.

Go: la prima lettera decide la visibilità

Go non ha le parole chiave public o private. Un nome a livello di package, un campo di una struct o un metodo è esportato se la sua prima lettera è maiuscola, e resta privato del suo package se è minuscola. Scegli tra l'una e l'altra cosa scegliendo tra PascalCase e camelCase.

package shapes

import "math"

// Circle is exported, so other packages can use it.
type Circle struct {
	Radius float64 // exported field
	label  string  // unexported field
}

// Area is exported.
func Area(c Circle) float64 { return math.Pi * square(c.Radius) }

// square is unexported: only code inside package shapes can call it.
func square(x float64) float64 { return x * x }

c := shapes.Circle{Radius: 2}
fmt.Println(shapes.Area(c))   // fine
fmt.Println(shapes.square(2)) // compile error: square is not exported

È anche per questo che Effective Go dice che il getter di un campo non esportato owner deve chiamarsi Owner, non GetOwner. La maiuscola ti dice già che è la via d'accesso pubblica.

React: i componenti devono avere la maiuscola

La documentazione di React non lascia spazio a dubbi: i nomi dei componenti devono iniziare con una lettera maiuscola, altrimenti non funzionano. JSX tratta un tag in minuscolo come <section> come un elemento HTML e uno con la maiuscola come <OrderSummary /> come un tuo componente.

Ruby: i nomi delle classi sono costanti

In Ruby, qualsiasi nome che inizia con una lettera maiuscola è una costante, e i nomi delle classi devono essere costanti. class Invoice funziona; class invoice è un errore di sintassi (“class/module name must be CONSTANT”).

Quale usare, linguaggio per linguaggio

• JavaScript e TypeScript: camelCase per variabili, funzioni, metodi e proprietà; PascalCase per classi, interfacce, alias di tipo, enum e componenti.
• Java e Kotlin: la stessa divisione, più maiuscole con underscore per le vere costanti (MAX_RETRIES).
• C#: PascalCase è molto più diffuso che negli altri linguaggi. Metodi, proprietà, eventi, campi pubblici, namespace e perfino le costanti sono in PascalCase; camelCase si usa per parametri e variabili locali, con _camelCase per i campi privati. Una firma tipica è public decimal CalculateTotal(decimal taxRate).
• Swift: PascalCase per tipi e protocolli, camelCase per tutto il resto.
• Go: quello che corrisponde alla visibilità che vuoi.
• Python: PascalCase solo per le classi. Funzioni e variabili sono in snake_case, e PEP 8 ammette camelCase solo dove è già lo stile prevalente in codice più vecchio.
• PHP (PSR-1): classi in PascalCase, metodi in camelCase.

Per costanti, file e tutto il resto, consulta la nostra guida rapida agli stili di scrittura per sviluppatori.

La parte difficile: sigle e acronimi

Si scrive userId o userID? HttpClient o HTTPClient? Le principali guide di stile danno risposte diverse:

La nostra opinione: se la guida del tuo linguaggio ha una regola, seguila, perché è quello che si aspettano la libreria standard e i tuoi colleghi. Se non ce l'ha, tratta le sigle come parole (HttpClient, userId). I confini tra le parole restano visibili quando due sigle si incontrano (confronta XMLHTTPRequest con XmlHttpRequest) e i nomi sopravvivono alla conversione automatica da uno stile all'altro. Perfino XMLHttpRequest, che è del browser stesso, mescola i due approcci in un solo nome.

Per approfondire, le convenzioni sulle maiuscole di Microsoft sono un buon esempio di un insieme completo di regole messo per iscritto in una sola pagina.

Convertire tra camelCase e PascalCase

Per un nome semplice, la conversione riguarda un solo carattere: basta passare la prima lettera da minuscola a maiuscola o viceversa.

const toPascal = (s) => s.charAt(0).toUpperCase() + s.slice(1);
const toCamel = (s) => s.charAt(0).toLowerCase() + s.slice(1);

toPascal("orderTotal"); // "OrderTotal"
toCamel("OrderTotal");  // "orderTotal"
toCamel("HTMLParser");  // "hTMLParser" (acronyms need a smarter split)

L'ultima riga spiega perché gli strumenti prima dividono i nomi in parole. Ecco cosa produce il convertitore di maiuscole/minuscole di ConvertCaseHQ con alcuni input difficili:

Il convertitore divide il testo in corrispondenza delle maiuscole già presenti e scrive le sigle come parole, in linea con la regola di Google. Se il tuo progetto segue le regole sulle sigle di Go, .NET o PEP 8, correggi quei nomi a mano dopo la conversione (in Go getUserId diventa getUserID). L'altra trappola sono i nomi di marchi: nessun algoritmo sa che IPhone ha un aspetto sbagliato.

Due errori facili da evitare

Il primo è mettere la maiuscola a un'istanza: const Cart = new ShoppingCart() fa sembrare Cart una seconda classe, e chi legge dopo di te andrà a cercarne la definizione. Il secondo è una funzione di supporto in PascalCase in JavaScript, come function FormatPrice(). A meno che non sia un costruttore o un componente React, chi legge darà per scontato che richieda new o JSX, e new-cap protesterà quando la chiami senza nessuno dei due.

Una regola pratica

Se è un tipo, o qualcosa che costruisci con new, usa PascalCase. Se è un valore o un'azione, usa camelCase. Lascia che sia la guida del tuo linguaggio a decidere sulle sigle e che un linter si ricordi il resto. Per i dettagli su JavaScript, comprese costanti e campi privati, leggi la nostra guida ai nomi delle variabili in JavaScript.