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

Nomi delle variabili in JavaScript: la guida per sviluppatori a camelCase

In JavaScript, dai alle variabili, alle funzioni, ai parametri e alle proprietà degli oggetti nomi in camelCase (cartTotal, fetchOrders), alle classi e ai componenti React nomi in PascalCase (ShoppingCart), e riserva CONSTANT_CASE ai valori che restano fissi per tutta la vita del programma (MAX_RETRIES). Le guide di stile JavaScript di Google e di Airbnb concordano fin qui, e anche gli oggetti integrati di JavaScript seguono lo stesso schema.

Il resto della guida spiega che cosa fa rispettare davvero il motore, poi le convenzioni che si aggiungono a quelle regole, poi i casi limite su cui i team non sono d'accordo: quali valori const meritano le maiuscole, i campi privati, le sigle e i dati in snake_case che arrivano da un'API.

Che cosa consente JavaScript stesso

Le regole del linguaggio sono poche. Un identificatore comincia con una lettera, un trattino basso o un simbolo del dollaro, e i caratteri successivi possono essere anche cifre. Le lettere non si limitano ad ASCII: l'esempio di MDN è la parola tedesca Früh. I nomi distinguono maiuscole e minuscole, quindi total e Total sono due variabili diverse, e le parole riservate come new, class e delete non si possono usare come nomi di variabile.

let total = 1;
let Total = 2;      // a different variable
const café = "ok";  // Unicode letters are allowed
const $price = 9.99;
const _unused = null;

// const 2fast = true;  // SyntaxError: can't start with a digit
// const new = 1;       // SyntaxError: reserved word

I nomi delle proprietà sono ancora più permissivi: va bene qualsiasi stringa se la metti tra virgolette, ed è così che è possibile headers["Content-Type"]. Tutto ciò che va oltre queste regole è convenzione, ed è proprio per questo che vale la pena mettersi d'accordo.

camelCase per variabili, funzioni e proprietà

camelCase è lo stile predefinito per quasi tutto ciò a cui dai un nome in JavaScript. Dai ai valori nomi di sostantivi e alle funzioni nomi di verbi, così una riga si legge come una frase:

const orderCount = orders.length;
const isLoggedIn = Boolean(session);
const user = { firstName: "Ada", lastLogin: null };

function calculateShipping(order) {
  // ...
}

Per i booleani, un prefisso is, has o can (isLoggedIn, hasAccess) risponde alla domanda “vero o falso riguardo a cosa?” prima che qualcuno debba farla. La guida di Google usa gli stessi prefissi per i getter booleani (isFoo, hasFoo).

La guida di Google ha anche una buona regola sulla lunghezza: sii descrittivo quanto ragionevolmente puoi, e non abbreviare cancellando lettere. errorCount e customerId vanno bene; nErr e cstmrId no. L'eccezione della guida è una variabile che resta nel suo ambito per dieci righe o meno, come la i in un ciclo breve o la x in points.map((x) => x * 2).

Collezioni, conteggi e gestori di eventi

Alcuni schemi rendono i nomi prevedibili. Usa il plurale per un array (users) e il singolare per un singolo elemento, così for (const user of users) si legge in modo naturale. Chiama un oggetto di ricerca in base alla sua chiave (usersById) e un numero in base a ciò che conta (userCount). In React, la documentazione descrive una convenzione diffusa per gli eventi: i gestori si chiamano handle più l'evento (handleClick), e le prop che accettano un gestore iniziano con on e una maiuscola (onClick, onSave).

PascalCase per classi, costruttori e componenti

Tutto ciò che costruisci con new prende PascalCase, e così tutto ciò che React renderizza come componente:

class ShoppingCart {
  addItem(item) {
    // ...
  }
}
const cart = new ShoppingCart();

function OrderSummary({ order }) {
  return <section>{order.id}</section>;
}

Per le classi è una convenzione. Per React è obbligatorio: la documentazione di React dice che i nomi dei componenti devono iniziare con una maiuscola, altrimenti non funzionano, perché JSX tratta i tag minuscoli come <section> come semplici elementi HTML. In TypeScript lo stesso PascalCase vale per interfacce, alias di tipo ed enum.

Gli oggetti integrati mostrano tutto questo. I costruttori sono in PascalCase (Map, Promise, Date), i metodi in camelCase (Object.fromEntries, Array.prototype.flatMap) e i valori fissi in maiuscolo (Math.PI, Number.MAX_SAFE_INTEGER).

Quando usare CONSTANT_CASE (e quando no)

Le costanti sono la fonte di più confusione, perché const non vuol dire “costante”. Impedisce solo di riassegnare la variabile; l'array o l'oggetto a cui punta può ancora cambiare. Entrambe le grandi guide di stile riservano le maiuscole a qualcosa di più rigoroso:

Google: CONSTANT_CASE è per i valori a livello di modulo (e le proprietà statiche) immutabili in profondità. Non basta l'intenzione di non cambiare mai un oggetto, e le costanti dichiarate dentro le funzioni restano in lowerCamelCase.
Airbnb: il maiuscolo è facoltativo, e solo per un valore esportato, dichiarato con const e di cui ci si può fidare (proprietà annidate comprese) che non cambierà mai. Mettere in maiuscolo ogni const dentro un file non è necessario.

// Module level, never changes: capitals
export const MAX_UPLOAD_BYTES = 5 * 1024 * 1024;
export const ORDER_STATUS = Object.freeze({ PENDING: "pending", SHIPPED: "shipped" });

function visibleNames(items) {
  const visible = items.filter((item) => !item.hidden); // const, but not a constant
  const names = [];                                     // const binding, mutable array
  for (const item of visible) names.push(item.name);
  return names;
}

Le guide divergono sulle chiavi di un oggetto simile a un enum. Google scrive i membri dell'enum in CONSTANT_CASE, come sopra; Airbnb preferisce chiavi minuscole dentro un export in maiuscolo. Una scelta o l'altra va bene se tutta la codebase fa lo stesso. Un'altra insidia: Object.freeze è superficiale, quindi un oggetto congelato può ancora contenere un oggetto annidato che cambia.

Campi privati: usa #, non il trattino basso

La vecchia abitudine di segnare i membri “privati” con un trattino basso iniziale (this._count) è solo un indizio; chiunque può ancora leggere e scrivere la proprietà. La guida di Airbnb dice di non usare trattini bassi iniziali o finali proprio per questo motivo, e anche la guida TypeScript di Google li vieta come prefissi e suffissi. Il JavaScript moderno ha veri campi privati:

class Counter {
  #count = 0;
  increment() {
    return ++this.#count;
  }
}

const counter = new Counter();
counter.increment();
counter.count;   // undefined
// counter.#count  // SyntaxError outside the class

Sigle: userId o userID?

La regola di Google è trattare le sigle come parole normali: customerId, xmlHttpRequest, loadHttpUrl. Quella di Airbnb è l'opposto: tenere una sigla tutta in maiuscolo o tutta in minuscolo, come in SMSContainer o httpRequests. Il browser stesso non sa decidersi, con XMLHttpRequest, innerHTML, getElementById e encodeURIComponent tutti nella stessa piattaforma.

Noi sceglieremmo la regola di Google, perché è prevedibile, mantiene visibili i confini tra le parole e si converte senza problemi da uno stile all'altro. Ma la coerenza conta più della scelta. Confrontiamo la regola sulle sigle di ogni guida importante in camelCase e PascalCase.

Gestire i dati snake_case delle API

Le API basate su Python, Ruby o un database SQL spesso ti consegnano chiavi come first_name. Non lasciare che si diffondano nel tuo codice. Rinominale nel punto in cui i dati arrivano, e la destrutturazione lo riduce a una riga:

const response = await fetch("/api/users/42");
const { first_name: firstName, last_login: lastLogin } = await response.json();

Per interi payload, scrivi una piccola funzione per ciascuna direzione che converta le chiavi in modo ricorsivo e chiamala nel tuo client API; ne vediamo una passo per passo in come convertire JSON da camelCase a snake_case. Per una rinomina occasionale, il nostro convertitore di maiuscole/minuscole trasforma last_login in lastLogin con un clic.

Fallo rispettare con ESLint

Due regole di base di ESLint coprono la maggior parte di questi casi. camelcase segnala i trattini bassi nel mezzo dei nomi, ignorando le costanti tutte in maiuscolo e i trattini bassi iniziali o finali. new-cap segnala new usato con un nome minuscolo, e una funzione con l'iniziale maiuscola chiamata senza new.

// eslint.config.js
export default [
  {
    rules: {
      camelcase: ["error", { properties: "never" }],
      "new-cap": "error",
    },
  },
];

L'opzione properties: "never" impedisce a camelcase di lamentarsi dei campi API come data.first_name, pur continuando a controllare le variabili che dichiari. Nei progetti TypeScript, @typescript-eslint/naming-convention va oltre e ti permette di impostare un formato consentito per ogni tipo di identificatore: variabili, funzioni, classi, parametri di tipo e altro. L'insieme completo delle regole di Google è nel Google JavaScript Style Guide.

Una checklist per i nomi delle variabili JavaScript

camelCase per variabili, funzioni, parametri, metodi e proprietà.
PascalCase per classi, costruttori, componenti React e tipi, interfacce ed enum di TypeScript.
CONSTANT_CASE per i valori a livello di modulo che non cambiano mai, non per ogni const.
Campi #private invece dei prefissi con trattino basso.
Un'unica regola sulle sigle, scritta nella guida per i contributori.
Chiavi API in snake_case convertite una volta sola, al confine.