camelCase

#

myVariableName

Le camelCase est la convention la plus connue. La majuscule en début de chaque mot (sauf le premier) permet de coller plusieurs mots tout en gardant une bonne lisibilité.

On la retrouve dans de nombreux langages :

• JavaScript : variables, fonctions.
• Java : variables, méthodes.
• TypeScript : idem, avec quelques variantes selon les guides de style.
• Go : utilise un mix, mais le camelCase reste courant.

Le camelCase existe en deux variantes :

• camelCase → minuscule au premier mot (courant pour variables et fonctions).
• CamelCase → majuscule dès le premier mot… mais dans ce cas on bascule vers le PascalCase utilisé pour des entités plus structurantes.

PascalCase

#

Exemple : UserProfile, DataFrameBuilder

Le PascalCase ressemble beaucoup au camelCase, mais commence par une majuscule.

On le retrouve dans des usages très codifiés :

• Java : noms des classes (StringBuilder).
• C# : classes, méthodes publiques.
• Python : classes, selon la PEP8.
• R : rarement utilisé, mais on le voit parfois pour des packages.

Historiquement, le nom vient du langage Pascal, qui imposait cette écriture pour les modules, types et programmes.

snake_case

#

Exemple : my_variable_name

Le snake_case sépare les mots avec des underscores. C’est probablement la convention la plus lisible, notamment en data, scripts et backend.

C’est la convention officielle dans plusieurs environnements :

• Python : variables, fonctions, modules (my_function, my_module).
• R : variables et fonctions (fortement encouragé dans le tidyverse).
• C : utilisé depuis les débuts du langage.
• Rust : variables et fonctions.
• PostgreSQL / SQL : pour les noms de colonnes et tables, c’est généralement la convention recommandée.

Deux avantages :

1. Les acronymes ne posent jamais problème (xml_http_request).
2. La lecture est plus rapide que le camelCase selon une étude de Kent State.

Inconvénient : un peu plus long à taper.

kebab-case

#

Exemple : my-variable-name

Le kebab-case est interdit dans la plupart des langages de programmation (le tiret étant interprété comme un opérateur). En revanche, il est partout ailleurs :

• URLs : /mon-article/les-conventions-de-nommage.
• Noms de fichiers web : my-component-name.css.
• Frameworks front : souvent utilisé pour les noms de composants dans Vue ou les custom elements Web Components (my-awesome-element).

On l’apprécie parce qu’il se lit très naturellement, y compris en dehors du code, et qu’il est utile pour le référencement SEO.

flatcase

#

Exemple : idontlikespace

Aucun séparateur, aucune majuscule. On le retrouve principalement dans un cas très précis :

• Java : nom maven/gradle des packages (com.company.project.app). Les points ne sont pas une convention de casse, mais un découpage hiérarchique.

En dehors de ce cas, il est rarement conseillé : la lisibilité chute, et on perd tout l’intérêt d’un nommage structuré.

UPPER_CASE

#

Exemple : MAX_RETRY_COUNT, CONFIG_PATH

L’upper case (avec underscores) est utilisée pour un rôle bien particulier :

• Constantes : en Python (MAX_SIZE), Java (DEFAULT_BUFFER), JavaScript (API_URL).
• Énumérations : selon les langages, c’est une convention admise.
• Variables globales : dans certains systèmes, où l’on veut les rendre très visibles.

On l’utilise peu, mais quand on l’utilise, c’est pour que ce soit impossible à rater.

Récap pour les langages

#

Remarques sur SQL :

• Le langage SQL lui-même n’impose rien (on peut écrire SELECT, select, ou SeLeCt).
• Pour les colonnes, tables, schémas, on utilise presque toujours snake_case.
• Les mots-clés SQL sont souvent en UPPER CASE, pour la lisibilité (SELECT id FROM users WHERE created_at > now()).