Camel case : exemples clairs pour nommer sans brouiller le code

Un identifiant mal nommé peut coûter plus de temps qu’une petite erreur de syntaxe, parce qu’il propage une mauvaise idée dans tout le projet. Le camel case paraît anodin, mais il touche les variables, les fonctions, les objets JSON, les API et parfois les noms de fichiers.

Fabien Coste l’aborde comme un formateur : pas pour imposer une religion du style, mais pour aider une équipe à lire le code sans traduction mentale permanente. Une convention claire vaut mieux qu’un mélange brillant sur trois fichiers.

Dans un dépôt réel, je garde une page de conventions avec des exemples camel case tirés du métier. Ce rappel limite les débats en revue et évite que chacun renomme selon son humeur du moment, surtout lors des corrections urgentes.

Définition du camel case avec des exemples immédiats

Le camel case consiste à écrire plusieurs mots sans espace, en mettant une majuscule au début des mots qui suivent le premier. En lowerCamelCase, le premier mot commence par une minuscule : nombreTentatives, adresseFacturation, utilisateurConnecte.

La forme rend visible la séparation des idées sans utiliser de tiret bas ni de trait d’union. Elle est très répandue en JavaScript, Java, TypeScript et dans de nombreuses API. Elle facilite aussi la complétion dans les éditeurs, car tout l’identifiant reste un seul bloc.

Le piège est de croire que le style suffit. total, totalCommande et montantTotalTtc n’expriment pas le même niveau de précision. Le camel case donne une forme, pas le sens. Le sens reste votre responsabilité.

Une bonne convention de nommage commence par des exemples réels du projet, pas par une définition copiée. Montrez comment nommer un client, une facture, une option d’interface et une réponse d’API. Le camel case devient alors un langage commun plutôt qu’une règle abstraite.

LowerCamelCase et PascalCase : une frontière simple

Point de contrôle	Ce que Fabien vérifie	Décision utile
Variable	dateDerniereConnexion	lowerCamelCase, rôle local
Classe ou composant	ProfilUtilisateur	PascalCase, type identifiable
Base SQL	date_derniere_connexion	snake_case souvent plus naturel

LowerCamelCase commence par une minuscule. On l’utilise souvent pour les variables, les fonctions et les propriétés : calculerPrix, dateDerniereConnexion, utilisateurActif. PascalCase commence par une majuscule : FactureClient, BoutonPrincipal, ProfilUtilisateur.

Cette différence visuelle aide à reconnaître le rôle d’un nom avant même de lire son contenu. Dans beaucoup de projets, une classe ou un composant en PascalCase se distingue d’une fonction en lowerCamelCase. Quand la convention est respectée, l’œil gagne du temps.

Ne mélangez pas les deux au hasard. Une fonction appelée CreerCompte ressemble à une classe. Une classe appelée profilUtilisateur ressemble à une variable. Ces petites incohérences ralentissent les revues de code et compliquent l’onboarding.

La prononciation mentale compte aussi. Si un identifiant se lit mal à voix haute, il se relira mal en revue. dateFinContrat se comprend immédiatement. dFinCtr ou dateContratFin obligent à deviner la logique de l’auteur.

Quand utiliser camel case selon les langages

JavaScript et TypeScript emploient fréquemment le camel case pour les variables, méthodes et propriétés. Java l’utilise aussi pour les méthodes, tandis que les classes passent plutôt en PascalCase. En C#, PascalCase gagne souvent plus de terrain côté méthodes publiques.

Python préfère snake_case pour les fonctions et variables. SQL utilise souvent snake_case ou des noms en minuscules. Le bon choix dépend donc de l’écosystème. Importer le style d’un langage dans un autre crée parfois une impression de code étranger.

Dans un projet multi-langage, écrivez une courte charte. Trois lignes suffisent : variables en lowerCamelCase dans le front, colonnes SQL en snake_case, types en PascalCase. Cette décision évite des débats inutiles dans chaque pull request.

Les générateurs de code et les clients API accentuent le problème. Une propriété mal nommée peut se retrouver dans des SDK, des tests et des documentations. Le camel case doit donc être décidé avant la publication d’un contrat, pas corrigé après les intégrations.

API, JSON et contrats : le nommage devient public

Dans une API, le nom d’une propriété peut rester visible pendant des années. Passer de firstName à first_name, ou de userID à userId, oblige parfois des clients à modifier leur code. Le camel case n’est donc plus une préférence interne : c’est un contrat.

Choisissez aussi une règle pour les acronymes. userId est souvent plus lisible que userID quand il s’insère dans une suite de mots, par exemple primaryUserId. Avec HTML, URL ou API, l’équipe doit décider si elle garde l’acronyme compact ou non.

Mon avis est net : un contrat public doit privilégier la stabilité à la pureté typographique. Si votre API expose déjà customerID partout, corriger pour faire joli peut coûter plus cher que documenter clairement la convention existante.

Dans les équipes débutantes, je conseille d’interdire les abréviations sauf liste partagée. max, min, id et url peuvent se défendre. usr, cfg ou tmp deviennent vite des pièges quand le fichier grandit.

Erreurs fréquentes qui rendent le code moins lisible

La première erreur consiste à empiler trop de mots : dateDerniereModificationUtilisateurAvantArchivage devient un commentaire déguisé. Quand un nom dépasse une idée simple, il faut parfois extraire une structure ou clarifier la responsabilité de la fonction.

La deuxième erreur est le mélange des langues. calculInvoiceTotal ou getUtilisateurActif fatigue inutilement. Une base de code française peut garder des noms métier en français et des verbes techniques cohérents, mais elle doit éviter l’alternance permanente.

La troisième erreur vient des booléens. actif, peutSupprimer et estArchive ne se lisent pas de la même façon dans une condition. Pour un booléen, préférez une formulation qui sonne vrai ou faux quand elle suit un if.

Les migrations de style se font mieux avec des outils de refactorisation qu’avec un remplacement texte global. Un éditeur qui comprend le langage évite de renommer une chaîne JSON, une colonne de base ou une clé attendue par un service externe.

Le même réflexe de prudence vaut pour une logique de sauvegarde déjà éprouvée, un exemple de support à préserver et une méthode de contrôle avant manipulation. Le contexte change, mais la méthode reste la même : identifier la source, protéger les données, vérifier le résultat.

Passer d’un style à l’autre sans casser un projet

Renommer tout un projet pour harmoniser le camel case est rarement prioritaire. Commencez par les nouveaux fichiers, puis par les zones que vous touchez déjà. Les changements massifs produisent des diffs illisibles et peuvent casser des sérialisations JSON ou des mappings.

Les outils de lint et de formatage aident, mais ils ne remplacent pas le jugement. Une règle automatique peut signaler un nom non conforme, pas décider si montantNetApresRemise est un bon modèle métier. La revue humaine reste utile.

Pour progresser proprement, ajoutez des exemples dans le README technique. Trois bons noms et trois noms refusés valent mieux qu’une page abstraite. Les développeurs copient ce qu’ils voient dans le dépôt.

Enfin, n’oubliez pas les tests. Si un renommage en camel case casse une sérialisation, un test d’API ou un snapshot doit le signaler. La convention sert la fiabilité, elle ne doit pas devenir une opération cosmétique sans filet.

Conclusion

Le camel case n’est pas une décoration de développeur. C’est une convention qui aide un lecteur à comprendre rapidement le rôle d’un identifiant. Choisissez lowerCamelCase, PascalCase ou snake_case selon le langage, puis tenez la règle. Les bons noms restent courts, cohérents et stables dans les contrats publics. Une équipe qui nomme clairement son code économise des heures de relecture, de revue et de correction silencieuse.

Questions fréquentes

Qu’est-ce que le camel case ?

C’est une convention de nommage qui colle plusieurs mots et met une majuscule au début des mots internes, par exemple dateCreationCompte.

Quelle différence entre camel case et PascalCase ?

Le camel case courant commence par une minuscule, alors que PascalCase commence par une majuscule. Les usages varient selon les langages.

Quand utiliser camel case ?

Utilisez-le quand l’écosystème du langage ou du projet le prévoit, surtout pour variables, fonctions, propriétés JSON et méthodes.