← Blog · 16 avril 2026 · L'équipe ConvertCaseHQ · 8 min de lecture

Convention de nommage des variables en JavaScript : le guide du camelCase

En JavaScript, nommez les variables, fonctions, paramètres et propriétés d'objet en camelCase (cartTotal, fetchOrders), les classes et les composants React en PascalCase (ShoppingCart), et réservez CONSTANT_CASE aux valeurs qui restent fixes pendant toute la vie du programme (MAX_RETRIES). Les guides de style JavaScript de Google et d'Airbnb s'accordent jusque-là, et les objets natifs de JavaScript suivent le même schéma.

Le reste de ce guide couvre ce que le moteur impose réellement, puis les conventions qui s'y ajoutent, puis les cas limites où les équipes divergent : quelles valeurs const méritent des majuscules, les champs privés, les sigles, et le snake_case qui arrive d'une API.

Ce que JavaScript autorise lui-même

Les règles du langage sont courtes. Un identifiant commence par une lettre, un tiret bas ou un signe dollar, et les caractères suivants peuvent aussi être des chiffres. Les lettres ne se limitent pas à l'ASCII : l'exemple de MDN est le mot allemand Früh. Les noms sont sensibles à la casse, donc total et Total sont deux variables différentes, et les mots réservés comme new, class et delete ne peuvent pas servir de noms de variables.

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

Les noms de propriétés sont encore plus souples : n'importe quelle chaîne convient si on la met entre guillemets, ce qui rend possible headers["Content-Type"]. Tout ce qui dépasse ces règles relève de la convention, et c'est justement pour cela qu'il vaut la peine de s'accorder.

camelCase pour les variables, fonctions et propriétés

camelCase est le réglage par défaut pour presque tout ce que vous nommez en JavaScript. Donnez des noms communs aux valeurs et des verbes aux fonctions, pour qu'une ligne se lise comme une phrase :

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

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

Pour les booléens, un préfixe is, has ou can (isLoggedIn, hasAccess) répond à la question « vrai ou faux pour quoi ? » avant que quiconque ait besoin de la poser. Le guide de Google emploie les mêmes préfixes pour les accesseurs booléens (isFoo, hasFoo).

Le guide de Google a aussi une bonne règle sur la longueur : soyez aussi descriptif que raisonnablement possible, et n'abrégez pas en supprimant des lettres. errorCount et customerId passent ; nErr et cstmrId non. L'exception du guide est la variable dont la portée tient en dix lignes ou moins, comme le i d'une courte boucle ou le x dans points.map((x) => x * 2).

Collections, compteurs et gestionnaires d'événements

Quelques schémas rendent les noms prévisibles. Mettez un pluriel pour un tableau (users) et le singulier pour un élément, de sorte que for (const user of users) se lise naturellement. Nommez un objet de correspondance d'après sa clé (usersById) et un nombre d'après ce qu'il compte (userCount). Dans React, la documentation décrit une convention courante pour les événements : les gestionnaires s'appellent handle suivi de l'événement (handleClick), et les props qui acceptent un gestionnaire commencent par on suivi d'une majuscule (onClick, onSave).

PascalCase pour les classes, constructeurs et composants

Tout ce que vous construisez avec new prend PascalCase, tout comme ce que React affiche comme composant :

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

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

Pour les classes, c'est une convention. Pour React, c'est obligatoire : la documentation de React dit que les noms de composants doivent commencer par une majuscule, faute de quoi ils ne fonctionnent pas, parce que JSX traite les balises en minuscules comme <section> comme de simples éléments HTML. En TypeScript, le même PascalCase s'applique aux interfaces, aux alias de types et aux enums.

Les objets natifs illustrent tout cela. Les constructeurs sont en PascalCase (Map, Promise, Date), les méthodes en camelCase (Object.fromEntries, Array.prototype.flatMap), et les valeurs fixes en majuscules (Math.PI, Number.MAX_SAFE_INTEGER).

Quand utiliser CONSTANT_CASE (et quand s'en abstenir)

Les constantes sont la source de la plus grande confusion, parce que const ne veut pas dire « constante ». Il empêche seulement de réaffecter la variable ; le tableau ou l'objet vers lequel elle pointe peut encore changer. Les deux grands guides de style réservent les majuscules à quelque chose de plus strict :

Google : CONSTANT_CASE est réservé aux valeurs de niveau module (et aux propriétés statiques) profondément immuables. La simple intention de ne jamais modifier un objet ne suffit pas, et les constantes déclarées dans des fonctions restent en lowerCamelCase.
Airbnb : les majuscules sont facultatives, et seulement pour une valeur exportée, déclarée avec const et dont on peut être sûr (propriétés imbriquées comprises) qu'elle ne changera jamais. Mettre en majuscules chaque const d'un fichier est inutile.

// 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;
}

Les guides se séparent sur les clés d'un objet de type enum. Google écrit les membres d'enum en CONSTANT_CASE, comme ci-dessus ; Airbnb préfère des clés en minuscules dans un export en majuscules. L'un comme l'autre convient si toute la base de code fait pareil. Un autre piège : Object.freeze est superficiel, un objet gelé peut donc encore contenir un objet imbriqué qui change.

Champs privés : utilisez #, pas un tiret bas

La vieille habitude de marquer les membres « privés » d'un tiret bas initial (this._count) n'est qu'un indice : n'importe qui peut encore lire et écrire la propriété. Le guide d'Airbnb dit de ne pas utiliser de tirets bas initiaux ou finaux précisément pour cette raison, et le guide TypeScript de Google les interdit aussi comme préfixes et suffixes. JavaScript moderne a de vrais champs privés :

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

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

Sigles : userId ou userID ?

La règle de Google est de traiter les sigles comme des mots ordinaires : customerId, xmlHttpRequest, loadHttpUrl. Celle d'Airbnb est l'inverse : garder un sigle entièrement en majuscules ou entièrement en minuscules, comme dans SMSContainer ou httpRequests. Le navigateur lui-même n'arrive pas à trancher, avec XMLHttpRequest, innerHTML, getElementById et encodeURIComponent au sein de la même plateforme.

Nous choisirions la règle de Google, parce qu'elle est prévisible, garde les limites de mots visibles et se convertit proprement d'un style de casse à l'autre. Mais la cohérence compte plus que le choix. Nous comparons la règle des sigles de chaque grand guide dans camelCase ou PascalCase.

Gérer les données en snake_case venues des API

Les API adossées à Python, Ruby ou une base SQL vous renvoient souvent des clés comme first_name. Ne les laissez pas se répandre dans votre code. Renommez-les au moment où les données arrivent ; la déstructuration en fait une seule ligne :

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

Pour des charges utiles entières, écrivez une petite fonction pour chaque sens qui convertit les clés de façon récursive, et appelez-la dans votre client d'API ; nous en détaillons une dans convertir du JSON camelCase en snake_case. Pour un renommage ponctuel, notre convertisseur de casse transforme last_login en lastLogin en un clic.

Le faire respecter avec ESLint

Deux règles de base d'ESLint couvrent l'essentiel. camelcase signale les tirets bas au milieu des noms, tout en ignorant les constantes en majuscules et les tirets bas initiaux ou finaux. new-cap signale new utilisé avec un nom en minuscules, ainsi qu'une fonction à initiale majuscule appelée sans new.

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

L'option properties: "never" empêche camelcase de se plaindre des champs d'API comme data.first_name tout en continuant à vérifier les variables que vous déclarez. Dans les projets TypeScript, @typescript-eslint/naming-convention va plus loin et permet de définir un format autorisé pour chaque sorte d'identifiant : variables, fonctions, classes, paramètres de type et plus encore. L'ensemble des règles de Google se trouve dans le Google JavaScript Style Guide.

Une liste de contrôle pour nommer ses variables JavaScript

camelCase pour les variables, fonctions, paramètres, méthodes et propriétés.
PascalCase pour les classes, constructeurs, composants React, et pour les types, interfaces et enums TypeScript.
CONSTANT_CASE pour les valeurs de niveau module qui ne changent jamais, pas pour chaque const.
Des champs #private plutôt que des préfixes en tiret bas.
Une seule règle pour les sigles, écrite dans votre guide de contribution.
Les clés d'API en snake_case converties une seule fois, à la frontière.