Conventions de dénomination: camelCase contre serpent_case contre kebab-case contre PascalCase

La célèbre blague de Phil Karlton dit qu'il n'y a que deux choses difficiles en informatique: l'invalidation du cache et le nommage des choses. Il est déjà assez difficile de choisir de bons mots; ensuite, il faut aussi décider comment les joindre. userId, user_id, UserId, user-id et USER_ID décrivent tous le même concept, et chacun est correct quelque part. Ce guide explique les principales conventions, où chacune est attendue, et comment gérer les cas difficiles acronymes, chiffres et limites entre systèmes.

Les principales conventions

Nom	Exemple	Utilisation typique
le cas du chameau	getUserById	Variables et fonctions JavaScript/TypeScript, méthodes Java, champs JSON
Le cas de Pascal	UserProfile	Classes, types, composants React, méthodes C#
cas de serpent	get_user_by_id	Python, Ruby, fonctions Rust, colonnes SQL
Je ne sais pas si je peux le faire.	MAX_RETRIES	Constantes, variables de l'environnement
cas de kebab	user-profile	URL, classes CSS, attributs HTML, noms de fichiers, drapeaux de l'interface utilisateur
Casse de train	Content-Type	Les en-têtes HTTP
point.case	app.server.port	Clé de configuration, paquets Java

Un [convertisseur de cas] ((/outils/convertisseur de cas) peut traduire n'importe quel nom entre tous ces éléments à la fois, ce qui est pratique lors du déplacement des données entre les couches.

Conventions par langue et contexte

JavaScript et typeScript

• Variables, fonctions et propriétés des objets: camelCase.
• Classes, interfaces, alias de type, énumérations et composants React: PascalCase. React exige que les composants commencent par une majuscule pour que JSX puisse les distinguer des éléments HTML.
• Véritables constantes (configuration qui ne change jamais): SCREAMING_SNAKE_CASE, bien que de nombreuses bases de code utilisent camelCase pour les variables const.
• Les noms de fichiers: souvent kebab-case (user-profile.tsx) ou PascalCase pour les fichiers composants. Choisissez l'un; cas mixte dans les noms de fichiers provoque des problèmes sur les systèmes de fichiers insensibles à la casse.

Python

PEP 8 est explicite: snake_case pour les fonctions, les variables et les modules, PascalCase (que PEP 8 appelle CapWords) pour les classes et SCREAMING_SNAKE_CASE pour les constantes au niveau du module. Un trait de soulignement avant indique "interne": _cache.

Vous allez ?

Go utilise camelCase et PascalCase, et la case a une signification: les identifiants commençant par une lettre majuscule sont exportés du paquet, les minuscules sont privés. Le style Go maintient les acronymes en majuscules: userID, HTTPServer, parseURL.

Java et C#

Les deux utilisent PascalCase pour les classes et camelCase pour les variables locales. Java utilise camelCase pour les méthodes; C# utilise PascalCase pour les méthodes et les propriétés publiques.

Résistance à la rouille

snake_case pour les fonctions, les variables et les modules; PascalCase pour les types et les traits; SCREAMING_SNAKE_CASE pour les constantes et les statiques. Le compilateur vous prévient quand vous déviez.

Base de données SQL

snake_case est le choix le plus sûr pour les tableaux et les colonnes. Dans PostgreSQL, les identifiants non cités sont pliés en minuscules, donc une colonne créée sous forme de "userId" doit être citée pour toujours, tandis que user_id fonctionne partout. Que les noms de table soient au singulier (user) ou au pluriel (users) dépend de la préférence de l'équipe; la cohérence compte plus que le choix.

CSS et HTML

Les propriétés CSS sont en case-caisse (background-color), donc les noms de classe suivent généralement: .card-header. Les méthodes telles que le BEM ajoutent une structure: .card__title--active. Les attributs HTML, y compris les attributs data-*, sont insensibles à la casse et conventionnellement à la casse; JavaScript expose data-user-id comme element.dataset.userId.

Les adresses

Utilisez kebab-case minuscule pour les chemins: /blog/compress-image-to-100kb. Google traite les tirets comme des séparateurs de mots mais souligne comme des jointures, donc les tirets sont meilleurs pour le référencement. Évitez les majuscules dans les URL; de nombreux serveurs traitent les chemins comme sensibles aux majuscules, ce qui crée des problèmes de contenu en double.

Variables de l'environnement

SCREAMING_SNAKE_CASE, DATABASE_URL, STRIPE_SECRET_KEY. Les shells et les plateformes de conteneurs s'y attendent, et certains n'autorisent pas du tout les tirets dans les noms de variables.

Les acronymes et les initiales

C'est là que les équipes se disputent le plus. Ça devrait être parseHTTPResponse ou parseHttpResponse? userID ou userId ?

• ** Traiter les acronymes comme des mots** (parseHttpResponse, userId, XmlParser): recommandé par les directives .NET de Microsoft pour les acronymes de plus de deux lettres, par les guides de style Java et JavaScript de Google et par de nombreuses bases de code TypeScript. Il évite les exécutions illisibles comme HTTPSURLConnection et convertit nettement entre les cas parseHttpResponse devient parse_http_response automatiquement.
• ** Gardez les acronymes en majuscules ** (parseHTTPResponse, userID): standard dans Go et commun dans les anciens codes Java et Objective-C.

Les convertisseurs automatiques divisent parseHTTPResponse en parse / HTTP / Response, ce qui fonctionne, mais HTTPSURLConnection est ambigu. Si vous contrôlez le style, traiter les acronymes comme des mots est plus robuste.

Numéros dans les noms

Gardez les chiffres attachés au mot auquel ils appartiennent: version2, utf8Decoder, base64_encode, h1-title. Évitez de commencer les identifiants avec des chiffres; la plupart des langages l'interdisent, et les classes CSS commençant par des chiffres nécessitent une évasion.

Traverser les frontières: API et bases de données

Les systèmes réels mélangent les conventions. Un backend Python avec snake_case sert un front-end JavaScript qui attend camelCase, soutenu par une base de données SQL avec des colonnes snake_case. Les options:

1. Utilisez une convention sur le fil. Décidez si JSON utilise camelCase (le choix le plus courant pour les API publiques, correspondant à JavaScript) ou snake_case (commun dans les écosystèmes Python et Ruby, et utilisé par les API telles que Stripe et GitHub). Documenter et appliquer partout.
2. Convertir aux bords. Les bibliothèques de sérialisation peuvent convertir automatiquement: les générateurs d'alias de Pydantic, les mappages de colonnes PropertyNamingStrategies de Jackson ou ORM. À l'intérieur de chaque couche, le code reste idiomatique.
3. Ne mélangez pas dans une même charge utile. { "userId": 1, "created_at": "..." } est le pire des deux mondes.

Lors de la génération de types TypeScript à partir de JSON couvert dans notre guide JSON à TypeScript conservez les noms de propriétés exactement tels qu'ils apparaissent sur le fil, et convertissez dans une couche de mappage si nécessaire.

Choisir de bons mots

Le style de l'affaire est la partie facile. Quelques règles pour les mots eux-mêmes:

• Soyez précis. data, info et item ne disent rien. invoiceLines en dit long.
• Utilisez des verbes pour les fonctions et des noms pour les valeurs. calculateTotal() renvoie total.
• ** Nommez les booléens comme questions.** isActive, hasAccess, shouldRetry.
• ** Inclure des unités.** timeoutMs, maxSizeBytes, durationSeconds empêchent toute une classe de bugs.
• ** Évitez les abréviations** à moins qu'elles ne soient universelles (id, url, html). usrCnt économise quatre personnages et coûte à chaque lecteur un moment.
• ** Correspondre à la langue du domaine.** Si l'entreprise dit "abonnement", ne l'appelle pas plan en code.

Exécution des conventions

Écrivez les conventions et laissez les outils les appliquer: la règle @typescript-eslint/naming-convention d'ESLint, Pylint et Ruff pour Python, golint et go vet, les lints intégrés de Rust et la stylelinte pour les modèles de classe CSS. Les contrôles automatisés mettent fin aux débats dans le cadre de la révision du code et maintiennent la cohérence des grandes bases de code.

Résumé

Utilisez camelCase pour les valeurs JavaScript, PascalCase pour les types et les composants, snake_case pour Python, Rust et SQL, kebab-case pour les URL, CSS et les noms de fichiers, et SCREAMING_SNAKE_CASE pour les constantes et les variables d'environnement. Traitez les acronymes comme des mots quand vous le pouvez, gardez les unités dans les noms, choisissez une convention pour chaque API, et laissez les linters appliquer les règles afin que les humains puissent se concentrer sur le choix de bons mots.