Aller au contenu
LeedyBox
Soutenir

Styles de casse et conventions de nommage expliqués

Les noms dans le code, les fichiers, les URL et les titres suivent des conventions qui varient d’un langage et d’un format à l’autre. Ce guide présente les styles de casse courants, où chacun est attendu, et les détails qui font trébucher : sigles, nombres, titres et lettres hors de l’anglais.

Les styles courants

StyleExempleConstruction
camelCaseorderTotalPremier mot en minuscules, mots suivants avec une majuscule initiale, sans séparateur
PascalCaseOrderTotalChaque mot avec une majuscule initiale, sans séparateur
snake_caseorder_totalMinuscules, mots reliés par _
CONSTANT_CASEORDER_TOTALMajuscules, mots reliés par _
kebab-caseorder-totalMinuscules, mots reliés par -
dot.caseorder.totalMinuscules, mots reliés par .
Title CaseOrder TotalMots séparés par des espaces, chacun avec une majuscule initiale
Sentence caseOrder totalSeul le premier mot a une majuscule initiale

On appelle parfois camelCase lower camel case et PascalCase upper camel case. CONSTANT_CASE est aussi appelé screaming snake case.

Le style attendu par chaque langage et chaque format

La plupart des écosystèmes ont adopté une convention depuis longtemps, et la suivre rend le code plus lisible pour quiconque connaît cet écosystème :

OùConvention habituelle
JavaScript, TypeScript, JavacamelCase pour les variables et les fonctions, PascalCase pour les classes, CONSTANT_CASE pour les constantes fixes
Python (PEP 8)snake_case pour les fonctions et les variables, PascalCase pour les classes, CONSTANT_CASE pour les constantes
C#PascalCase pour les types, les méthodes et les membres publics ; camelCase pour les variables locales et les paramètres
GoPascalCase exporte un nom hors de son paquet, camelCase le garde privé
Ruby, Rustsnake_case pour les méthodes et les variables, PascalCase pour les types
CSS et HTMLkebab-case pour les propriétés, les noms de classe et les attributs data-
URLkebab-case ; Google recommande des traits d’union plutôt que des tirets bas entre les mots
Tables et colonnes SQLsnake_case, car beaucoup de bases de données ramènent les noms sans guillemets à une seule casse
Variables d’environnementCONSTANT_CASE, comme DATABASE_URL
Clés de configurationdot.case pour les réglages imbriqués, comme server.port
API JSONPas de règle unique : beaucoup utilisent camelCase, d’autres snake_case ; suivez l’API avec laquelle vous travaillez

Le kebab-case est impossible pour les noms de variables dans la plupart des langages de programmation, car le trait d’union est lu comme un signe moins : order-total signifie order moins total.

Sigles et nombres

C’est sur les sigles que les conventions divergent le plus. Une école les garde en majuscules (userID, parseHTML) ; une autre les traite comme des mots ordinaires (userId, parseHtml). Les guides de style Java et JavaScript de Google suivent la seconde approche, qui garde les frontières de mots nettes quand des sigles se suivent : XmlHttpRequest se découpe plus facilement que XMLHTTPRequest. Les règles .NET de Microsoft gardent en majuscules les sigles de deux lettres (IOStream) et ne mettent en majuscule que la première lettre des plus longs (HtmlButton). L’API de navigateur XMLHttpRequest mélange les deux, d’où son statut fréquent de contre-exemple.

Les chiffres n’ont pas de casse, donc un convertisseur ne peut pas savoir si utf8Decoder signifie « utf8 decoder » ou « utf 8 decoder ». Les convertisseurs rattachent généralement un nombre au mot qui le précède. Choisissez une graphie et utilisez-la partout.

Title Case et Sentence case dans les titres

Pour les titres en anglais, les guides de style ne mettent pas une majuscule à tous les mots de la même façon. Les styles AP et Chicago laissent en minuscules les articles, conjonctions et prépositions courts, sauf en début ou en fin de titre (« The Lord of the Rings »), et ne s’accordent pas sur la liste exacte. Beaucoup de guides d’interface et de documentation, dont ceux de documentation pour développeurs de Microsoft et de Google, préfèrent le Sentence case (« Change your password »), plus facile à appliquer de manière cohérente et moins formel.

Le Title Case du convertisseur LeedyBox met une majuscule à chaque mot, ce qui convient aux libellés et aux noms de type variable, mais pas à un titre de presse : repassez ensuite les petits mots en minuscules à la main.

Convertir entre styles fait perdre de l’information

Toute conversion découpe d’abord un nom en mots, en s’appuyant sur les majuscules et les séparateurs, puis assemble ces mots dans le nouveau style. Ce que le style cible ne sait pas exprimer disparaît : parseHTML devient parse_html, et la conversion inverse donne parseHtml. La ponctuation disparaît aussi, si bien que « don't » devient deux mots.

Traitez donc un seul style comme référence. Si une base de données utilise snake_case et le code camelCase, convertissez à la frontière à chaque fois, dans le même sens, plutôt que de stocker les noms sous les deux formes.

Renommer des clés à la frontière d’une API

Quand un front-end en camelCase dialogue avec un back-end en snake_case, la plupart des bibliothèques de sérialisation peuvent faire correspondre les noms automatiquement, si bien que les données ne sont jamais renommées à la main. Convertir une fois un document JSON, par exemple des données de test ou une réponse d’exemple, est une autre tâche, et le mode « Clés JSON » du convertisseur la réalise sans toucher aux valeurs.

Attention aux collisions : user_name et userName deviennent la même clé dans l’un ou l’autre style, et l’une écraserait l’autre. Les symboles initiaux comme _id ou $ref ont souvent un sens pour une base de données ou un schéma précis ; vérifiez donc s’ils peuvent être renommés.

Majuscules et minuscules au-delà de l’anglais

Les règles de casse ne sont pas les mêmes dans toutes les langues. Le ß allemand devient SS en majuscules, le mot s’allonge donc. Le turc a un i avec point et un ı sans point : leurs paires en majuscules sont i → İ et ı → I, alors que la règle par défaut de la plupart des langages de programmation transforme i en I. toUpperCase() en JavaScript applique la règle par défaut ; toLocaleUpperCase('tr') applique la règle turque. Le coréen, le chinois et le japonais n’ont pas du tout de casse : seuls les séparateurs entre les mots changent.

La casse peut aussi compter pour les noms de fichiers. Windows et, par défaut, macOS considèrent Readme.md et README.md comme le même fichier, alors que Linux y voit deux fichiers. Un renommage qui ne change que la casse peut donc passer inaperçu sur un système et casser des liens ou des imports sur un autre.

Questions fréquentes

Vaut-il mieux camelCase ou snake_case ?

Aucun n’est meilleur en général. Suivez la convention du langage, du framework ou de l’API que vous utilisez ; la cohérence au sein d’une même base de code compte plus que le choix lui-même.

Les URL doivent-elles utiliser des traits d’union ou des tirets bas ?

Des traits d’union. Les recommandations de Google sur les URL conseillent des traits d’union entre les mots, et les slugs en kebab-case comme /case-converter/ sont la pratique courante sur le web.

Pourquoi Git ne remarque-t-il pas que j’ai seulement changé la casse d’un nom de fichier ?

Sur un système de fichiers insensible à la casse, Git traite souvent l’ancien et le nouveau nom comme le même fichier. Renommez avec git mv, par exemple en passant par un nom temporaire, pour que le changement soit enregistré pour les systèmes où la casse compte.

Comment écrire un nom de marque comme iPhone ou eBay en camelCase ?

Les convertisseurs coupent aux majuscules, ces noms ressortent donc en mots séparés. Dans le code, il est généralement plus clair de traiter la marque comme un seul mot (iphoneModel) et de réserver sa graphie officielle au texte destiné aux personnes.