Bien nommer ses variables et fonctions : bonnes pratiques

Il existe une citation célèbre chez les développeurs : il n’y a que deux problèmes difficiles en informatique, l’invalidation de cache et nommer les choses. La blague dit vrai : trouver le bon nom est un petit effort constant, mais c’est lui qui sépare un code limpide d’un labyrinthe. Ces bonnes pratiques de nommage pour tes variables et tes fonctions se maîtrisent en une lecture et s’appliquent dès ton prochain fichier, où que tu en sois dans le parcours apprendre à coder.

Pourquoi le nom compte plus que tu ne crois

Une évidence d’abord, que les débutants découvrent toujours trop tard : le code s’écrit une fois, mais se relit des dizaines de fois. Par toi la semaine prochaine, par toi dans six mois quand un bug ressurgit, par un collègue, par un recruteur qui parcourt ton dépôt GitHub. Et à la relecture, la machine n’aide plus : pour elle, x et prixTotalTTC sont parfaitement équivalents. La différence n’existe que pour les humains, et elle est énorme. Compare if (a > b) { c = a * 0.9; } avec if (montantPanier > seuilRemise) { prixFinal = montantPanier * 0.9; } : le second se lit comme une phrase, sans un seul commentaire. C’est toute la philosophie : un bon nom rend le commentaire inutile, parce qu’il porte lui-même l’explication. Une variable bien nommée dit ce qu’elle contient ; une fonction bien nommée dit ce qu’elle fait, et ce qu’elle rend.

De là découlent les trois règles de grammaire du nommage. Un : les variables portent des noms (au sens grammatical), car elles désignent des choses : utilisateur, listeCommandes, dateInscription. Deux : les fonctions portent des verbes, car elles font des actions : calculerTotal(), envoyerEmail(), chargerProfil(). Une fonction nommée total() laisse un doute (elle calcule le total ? elle le renvoie ? elle l’affiche ?) que calculerTotal() dissipe. Trois : les booléens posent une question dont la réponse est oui ou non : estConnecte, aPaye, peutModifier (en anglais : isValid, hasChildren, canEdit). Le gain se voit dans les conditions : if (estConnecte) se lit à voix haute comme du français. Ces trois règles couvrent à elles seules l’immense majorité des situations, et transforment déjà la lisibilité des premiers projets.

Les conventions : parler la langue de ton langage

Chaque langage a son accent, et le respecter n’est pas de la coquetterie : c’est ce qui permet à n’importe quel développeur de lire ton code sans friction. En Python, la norme officielle (le fameux document PEP 8) impose le snake_case : mots en minuscules séparés par des tirets bas, prix_total, envoyer_email(). En JavaScript, en Java et dans la plupart des langages à accolades, c’est le camelCase : première lettre minuscule, puis une majuscule à chaque mot, prixTotal, envoyerEmail(). Deux conventions traversent presque tous les langages : le PascalCase (majuscule partout, PanierClient) est réservé aux classes, et le UPPER_SNAKE_CASE (TAUX_TVA, MAX_TENTATIVES) aux constantes, ces valeurs qui ne changent jamais. Adopte la convention de ton langage dès le premier jour : mélanger les styles dans un même fichier est le signe distinctif du code de débutant.

Reste la question de la longueur, et elle a une réponse élégante : la taille du nom suit la taille de sa portée. Un compteur qui vit trois lignes dans une boucle peut s’appeler i, c’est une convention universelle et parfaitement lisible. Une variable qui traverse cinquante lignes mérite un vrai nom. Une fonction publique utilisée dans tout le projet mérite le nom le plus explicite de tous, même s’il est long : calculerFraisLivraison() vaut mieux que calcFL(). Méfie-toi des abréviations maison (usr, btn, tmp) : tu gagnes une seconde à l’écriture et tu en perds dix à chaque relecture. Méfie-toi surtout des noms muets : data, info, result, chose, machin ne disent rien (tout est de la donnée, tout est un résultat). Et méfie-toi des jumeaux trompeurs : listeClient et listeClients dans le même fichier, c’est un bug en gestation.

Français ou anglais, renommage et cohérence

La question arrive vite quand on apprend en français : nommer en français ou en anglais ? Les deux se défendent pour un projet personnel, mais l’écosystème a tranché : l’anglais est le standard du métier. Les langages eux-mêmes sont en anglais (if, for, return), les bibliothèques aussi, et un code mi-français mi-anglais (getPrixTotal()) fatigue l’œil. Si tu vises un emploi ou l’open source, prends l’habitude de l’anglais tôt : le vocabulaire nécessaire est étroit (get, set, create, delete, update, count, list…) et se retrouve partout, y compris dans la documentation technique. Si tu débutes tout juste et que l’anglais ajoute une charge mentale de trop, nomme en français sans accents ni espaces, mais fais-le PARTOUT : la règle d’or, au-dessus de toutes les autres, est la cohérence. Un projet où la même idée s’écrit tantôt user, tantôt utilisateur, tantôt client devient illisible, même si chaque nom pris isolément est correct.

Dernier super-pouvoir, trop peu connu des débutants : renommer ne coûte rien. Tu n’es pas marié à tes noms. Quand tu comprends mieux ton programme et qu’un meilleur nom t’apparaît, applique-le : dans VS Code, place le curseur sur le nom, appuie sur F2, tape le nouveau nom, et toutes les occurrences du projet sont mises à jour d’un coup, sans risque d’en oublier une (le rechercher-remplacer texte, lui, peut casser des choses). Ce geste figure d’ailleurs parmi les raccourcis qui font gagner du temps. Prends l’habitude de relire tes noms à la fin de chaque séance, comme on relit un texte : c’est le moment idéal, juste avant de commiter. Un code aux noms justes se relit sans effort, se débogue deux fois plus vite, et raconte à quiconque l’ouvre que son auteur savait ce qu’il faisait. C’est, très littéralement, la politesse du développeur.

Questions fréquentes

camelCase ou snake_case : lequel choisir ?

Ce n’est pas un choix personnel mais une convention de langage : snake_case en Python (prix_total), camelCase en JavaScript et en Java (prixTotal). Le PascalCase est réservé aux classes et le UPPER_SNAKE_CASE aux constantes dans presque tous les langages. Suis la convention de ton langage : ton code sera immédiatement lisible par les autres développeurs.

Peut-on nommer ses variables en français ?

Techniquement oui (sans accents ni espaces), et c’est acceptable pour un projet personnel de débutant. Mais l’anglais est le standard professionnel : langages, bibliothèques et documentation sont en anglais, et un code bilingue fatigue à la lecture. Le vocabulaire utile est réduit (get, create, delete, count…), autant le prendre tôt. Quel que soit ton choix, applique-le à tout le projet.

Quelle est la longueur idéale d’un nom de variable ?

Proportionnelle à sa durée de vie : une lettre (i, j) pour un index de boucle de trois lignes, un nom complet et explicite pour tout ce qui vit plus longtemps ou traverse plusieurs fonctions. Un nom long et clair comme calculerFraisLivraison vaut toujours mieux qu’une abréviation maison illisible. C’est la relecture qu’on optimise, pas la frappe.

Comment renommer une variable sans rien casser ?

Utilise la fonction de renommage de ton éditeur plutôt qu’un rechercher-remplacer : dans VS Code, place le curseur sur le nom et appuie sur F2. L’éditeur comprend le code et met à jour toutes les occurrences réelles du symbole, sans toucher aux mots identiques qui n’ont rien à voir. Renomme dès qu’un meilleur nom t’apparaît : c’est gratuit et le code y gagne à chaque fois.

Sources

• PEP 8, la convention de style officielle du langage Python
• Les guides de style publics de Google (JavaScript, Python, Java…)

Cet article a une vocation informative et pédagogique. Les plateformes, outils et formations éventuellement cités le sont à titre d’exemple ; compare plusieurs options avant de t’engager ou de payer.