Vous Devriez Soigner la Mise en Forme des Noms dans Votre Code

Vous Devriez Soigner la Mise en Forme des Noms dans Votre Code

Table des matières

Dans mon code, je dois définir une variable pour représenter « my new item ». Mais comment la nommer ? Dois-je écrire : “mynewitem”, “myNewItem”, “MyNewItem”, “MYNEWITEM”, “MY_NEW_ITEM”, “My_New_Item”, “my_New_Item” ou “my_new_item” ?

Est-ce que la mise en forme du nom d’une variable — ou de n’importe quel élément de code — a vraiment une importance ? La réponse est oui, clairement.

Comme pour la langue anglaise, la façon dont vous formatez les noms dans votre code influence énormément la lisibilité.

Dans cet article, je vous explique pourquoi le formatage compte et comment bien structurer les noms dans votre code.

​
Pourquoi les conventions de nommage sont importantes

Prenons ces deux fonctions issues de CPython, l’interpréteur du langage Python :

  • PyList_SetItem
  • PyList_SET_ITEM

À première vue, elles semblent représenter la même idée : “Py List Set Item”. Pourtant, elles n’ont pas du tout le même rôle :

  • PyList_SetItem est une fonction.
  • PyList_SET_ITEM est une macro.

Comment le sait-on ? Parce que CPython applique cette convention de manière cohérente, ce qui permet de distinguer immédiatement les fonctions des macros.

De plus :

  • PyList_SetItem effectue des vérifications d’erreurs.
  • PyList_SET_ITEM n’en fait pas (ce qui est courant pour les macros CPython).

Vous voyez tout ce que l’on peut comprendre rien qu’en regardant le nom — sans ouvrir la doc ?

C’est tout l’intérêt d’un bon format de nommage.

​
Comment formater vos noms ?

​
Étape 1 : Décrire ce que représente l’élément

Avant de penser au format, décrivez simplement ce que fait ou représente l’élément. Par exemple :

  • Une fonction qui récupère les données d’un utilisateur → “fetch user data”
  • Une constante pour le nombre maximum d’essais → “max retries”

Vous trouverez plus de détails dans mon article: Des noms de variables descriptifs ne sont pas toujours une bonne idée, ainsi que dans les articles suivants 1 2 3 4 5.

​
Étape 2 : Appliquer le bon format

Ensuite, transformez votre description en un format adapté au code.

Voici les principaux styles de nommage et leurs usages habituels :

  1. Flat Case (calculatetotal)

    • Tout en minuscule, sans séparateur.
    • Rarement conseillé : peu lisible.

  2. Camel Case (parseHtmlInput)

    • Premier mot en minuscule, suivants en majuscule.
    • Très utilisé pour les fonctions JavaScript.

  3. Pascal Case (DatabaseConnection)

    • Chaque mot commence par une majuscule.
    • Usuel pour les noms de classes en Python, Java et C#.

  4. Upper Case (MAXVALUE)

    • Tout en majuscule, sans séparateur.
    • Rarement recommandé pour la lisibilité.

  5. Snake Case (max_retries)

    • Mots en minuscule séparés par des underscores.
    • Courant pour les variables Python et les macros C.

  6. Screaming Snake Case (DEFAULT_TIMEOUT)

    • Version majuscule du snake case.
    • Souvent utilisé pour les constantes Python et Java.

  7. Camel Snake Case (http_Response_Code)

    • Mélange camel + snake.
    • Rare mais utile pour organiser logiquement certaines valeurs.

  8. Pascal Snake Case (Xml_Parser_Config)

    • Mélange Pascal + snake.
    • Parfois utilisé dans certaines API.

  9. Kebab Case (background-color)

    • Mots en minuscule séparés par des tirets.
    • Fréquent en CSS ou dans les URLs. Non valide dans la plupart des langages.

  10. Screaming Kebab Case (API-ENDPOINT)

  • Comme le précédent, mais en majuscules.
  • Souvent utilisé pour les variables d’environnement. Non valide dans la majorité des langages.
  1. Train Case (User-Profile-Page)
  • Mots capitalisés séparés par des tirets.
  • Utilisé pour des noms de fichiers. Non valide dans la plupart des langages.

Note

Il n’y a aucune règle universelle pour gérer les nombres ou acronymes dans les noms. Exemples :

  • PascalCase : XmlParserConfig vs XMLParserConfig
  • Snake Case : value1 vs value_1

Chaque guide de style doit choisir une option et s’y tenir.

Certains projets, comme CPython, mélangent même plusieurs formats pour créer un style propre. Par exemple PyList_CheckExact est un mélange de PascalCase et snake_case, ce qui aide à regrouper les fonctions liées en C, où les namespaces n’existent pas.

​
Règles spécifiques à certains langages

Certains langages, comme Go, imposent des conventions de nommage directement dans leur design. En Go, une simple majuscule suffit à indiquer si un élément est public ou privé.

example.go (module utilisé)

1package example
2
3// Exporté (public) car commence par une majuscule
4var MyItem = "I am visible outside the package"
5
6// Non exporté (privé) car commence par une minuscule
7var myItem = "I am not visible outside the package"

main.go (important le module)

 1package main
 2
 3import (
 4    "fmt"
 5    "example"
 6)
 7
 8func main() {
 9    // ✅ OK
10    fmt.Println(example.MyItem)
11
12    // ❌ Erreur de compilation
13    // fmt.Println(example.myItem) 
14}

Dans example.go, MyItem est exporté, myItem ne l’est pas.

Cette règle simple rend immédiatement visible ce qui appartient à l’API publique.

​
Bonnes pratiques pour les conventions de nommage

​
Vous démarrez un nouveau projet ?

  • Définissez une convention claire dès le début.
  • Suivez le guide officiel du langage.
  • S’il n’y en a pas, utilisez le style le plus courant dans la communauté.

​
Vous travaillez sur un projet existant ?

  • Restez cohérent avec le style déjà en place.
  • Évitez de mélanger plusieurs formats sans raison valable.

​
Vous hésitez sur un nom ?

​
Pour conclure

Les conventions de nommage ne sont pas un détail. Elles sont la base d’un code clair, durable et facile à maintenir.

1️ Choisissez un style. 2️ Respectez-le. 3️ Appliquez-le partout dans votre projet.

📌 Voici les conventions recommandées pour C#, Go, Python et Rust !

📌 Vous voulez une référence pratique ? Recevez gratuitement notre fiche mémo des conventions de nommage directement par email ! Renseignez vos infos ci-dessous.

  1. Clean Code Naming Conventions - Pabashani Herath ↩︎

  2. Guide to naming in code - Dmitriy Matison ↩︎

  3. Naming things properly - Tom Kwong’s Infinite Loop ↩︎

  4. How to properly name things as a developer - Niwat ↩︎

  5. A Guide to Clean Code: The Power of Good Names - Gervais Yao Amoah ↩︎

Étiquettes :
Partager :

Articles Connexes

Fatigué de Débattre du Style de Code ? Automatisez Votre Chemin vers la Cohérence

Fatigué de Débattre du Style de Code ? Automatisez Votre Chemin vers la Cohérence

Comment Faire Parler Votre Terminal en Couleur (avec les Codes ANSI)

Comment Faire Parler Votre Terminal en Couleur (avec les Codes ANSI)

Transformez un terminal gris et monotone en texte coloré et lisible qui parle vraiment votre langage. Vous êtes déjà resté plissé devant un mur de …

Lire la suite
Nommer les variables : quand la description est de trop

Nommer les variables : quand la description est de trop

Quand on nomme des variables dans un programme, le conseil habituel est d’utiliser des noms descriptifs. Mais est-ce toujours vrai ? Voyons …

Lire la suite