← Blog · 19 avril 2026 · L'équipe ConvertCaseHQ · 7 min de lecture

camelCase, snake_case, kebab-case : aide-mémoire des conventions de nommage par langage

Voici la version courte. Les types et les classes s'écrivent en PascalCase dans presque tous les langages. Les variables et les fonctions s'écrivent en camelCase en JavaScript, Java, C#, Kotlin et Swift, mais en snake_case en Python, Ruby et Rust. Les constantes s'écrivent en SCREAMING_SNAKE_CASE dans la plupart des langages, avec pour exceptions Go, Swift, C# et le C++ au style Google. Tout ce qui se retrouve dans une URL, un fichier CSS ou un nom de paquet est généralement en kebab-case minuscule, et les variables d'environnement sont en majuscules avec des tirets bas.

Voilà le schéma général. C'est sur les détails qu'on se dispute en revue de code : cet aide-mémoire s'en tient donc à ce que dit réellement le guide de style officiel, ou le plus répandu, de chaque langage, et cite la source pour chacun.

camelCase, snake_case, kebab-case : les cinq styles et leurs autres noms

• camelCase (orderTotal) : premier mot en minuscules, chaque mot suivant avec une majuscule initiale. On parle aussi de lowerCamelCase ; PEP 8 l'appelle mixedCase.
• PascalCase (OrderTotal) : chaque mot avec une majuscule initiale. On parle aussi d'UpperCamelCase, de CapWords (PEP 8) ou de StudlyCaps (PSR-1 de PHP).
• snake_case (order_total) : mots en minuscules reliés par des tirets bas.
• SCREAMING_SNAKE_CASE (ORDER_TOTAL) : mots en majuscules reliés par des tirets bas. Le guide JavaScript de Google l'appelle CONSTANT_CASE, et son guide Java UPPER_SNAKE_CASE.
• kebab-case (order-total) : mots en minuscules reliés par des traits d'union. La plupart des langages ne peuvent pas l'employer pour des identifiants, car le trait d'union est un signe moins.

Pour passer un nom d'un style à l'autre, collez-le dans notre convertisseur de casse. Il découpe aux espaces, aux tirets bas, aux traits d'union et aux majuscules existantes : order_total, order-total et OrderTotal se convertissent donc proprement les uns en les autres. Traitez toutefois un seul nom à la fois : il considère tout ce que contient la zone comme un identifiant unique.

Aide-mémoire : conventions de nommage par langage

Quelques lignes appellent une note. En Go, la première lettre n'est pas du tout un choix de style : c'est la règle de visibilité. Area est exporté depuis son paquet, area ne l'est pas, et le compilateur l'impose. C++ n'a pas de convention valable pour tout le langage ; la bibliothèque standard elle-même emploie snake_case (std::unordered_map, push_back). Voyez donc la ligne Google comme une option bien documentée, pas comme la règle.

Rust est particulièrement strict sur le style. Le compilateur vous avertit d'office : écrivez fn GetUser() ou struct user_account, et rustc suggère get_user et UserAccount avant même que vous ayez lancé un linter.

Noms de fichiers, de modules et de paquets

• Java : une classe publique de premier niveau doit se trouver dans un fichier qui porte exactement son nom, majuscules comprises. OrderService va dans OrderService.java, et javac refuse tout autre nom.
• Kotlin : un fichier qui contient une seule classe porte le nom de cette classe. Les autres fichiers reçoivent un nom descriptif en UpperCamelCase, comme ProcessDeclarations.kt.
• Python : les modules reçoivent des noms courts, entièrement en minuscules, avec des tirets bas s'ils améliorent la lisibilité. Les paquets doivent eux aussi être courts et en minuscules, et PEP 8 y déconseille les tirets bas.
• Ruby : des fichiers en snake_case, nommés d'après la classe qu'ils contiennent : HelloWorld se trouve donc dans hello_world.rb.
• Go : les noms de paquets sont des mots uniques en minuscules, sans tirets bas ni mixedCaps : base64, et non encoding_base64 ou encodingBase64.
• JavaScript et TypeScript : pas de règle unique. Le guide JavaScript de Google veut des noms de fichiers tout en minuscules, avec des tirets bas ou des traits d'union, et son guide TypeScript emploie snake_case. Le guide d'Airbnb dit qu'un nom de fichier doit correspondre à son export par défaut : une classe CheckBox se trouve donc dans CheckBox.js. Choisissez une règle par projet et écrivez-la noir sur blanc.
• Paquets npm : les noms des nouveaux paquets ne peuvent pas du tout contenir de majuscules.

Au-delà du code source : variables d'environnement, CSS, HTML, URL, JSON et SQL

Une particularité des variables d'environnement : selon POSIX, les utilitaires standard emploient des noms en majuscules, et les noms qui contiennent des minuscules sont réservés aux applications, de sorte qu'un nom en minuscules ne peut jamais entrer en conflit avec un nom standard. Les majuscules restent pourtant l'usage établi ; nous les garderions donc, en ajoutant plutôt un préfixe distinctif (MYAPP_TIMEOUT) pour éviter les conflits.

Les lignes sur CSS et SQL ont chacune leur propre article : voyez le nommage CSS et BEM pour les noms de classes, et les conventions de nommage SQL pour comprendre pourquoi les bases de données vous poussent vers les minuscules.

Sigles : là où les guides de style divergent

Tous les guides s'accordent sur userName. Ils se divisent sur userID. Les guides JavaScript et Java de Google mettent les sigles en minuscules comme des mots ordinaires (xmlHttpRequest, customerId). Go garde chaque sigle entièrement dans une seule casse (ServeHTTP, appID). Les directives .NET de Microsoft mettent en majuscules les deux lettres d'un sigle de deux lettres (IOStream), mais seulement la première lettre des sigles plus longs (HtmlTag). Rust les traite comme des mots (Uuid), et PEP 8 préfère HTTPServerError à HttpServerError. Nous comparons les options côte à côte dans camelCase ou PascalCase.

Comment choisir quand on hésite

1. Vérifiez si la plateforme décide pour vous. Les noms de propriétés CSS, les noms de fichiers Java, les noms exportés de Go et les noms de composants React (qui doivent commencer par une majuscule) ne relèvent pas du choix de style.
2. Suivez le guide officiel du langage. Le nouveau code doit ressembler à la bibliothèque standard qu'il côtoie.
3. Alignez-vous sur le projet existant. PEP 8 le dit sans détour : la cohérence au sein d'un projet compte plus que la cohérence avec le guide de style.
4. Laissez un linter s'en souvenir. La règle camelcase d'ESLint, les règles N de Ruff pour Python et les avertissements intégrés de rustc rattrapent les écarts avant qu'un relecteur n'ait à le faire.
5. Convertissez une fois, à la frontière. Quand du JSON en snake_case rencontre du JavaScript en camelCase, renommez les clés dans une seule couche de sérialisation au lieu de laisser les deux styles se répandre dans toute la base de code.