Clean code : écrire du code lisible et maintenable
Le clean code — le « code propre » — désigne un ensemble de principes visant à rendre le code facile à lire, à comprendre et à modifier. Ce n’est pas une affaire d’esthétique : un logiciel passe bien plus de temps à être lu et maintenu qu’à être écrit. Un code clair réduit les bugs, accélère l’intégration des nouveaux venus et diminue le coût de chaque évolution. Ce guide fait le tour des grands principes du clean code, exemples avant/après à l’appui, et rappelle qu’aucune règle ne doit devenir un dogme.
Pourquoi le clean code compte
Une ligne de code est écrite une fois, mais relue des dizaines de fois : lors d’une correction de bug, d’une revue, d’une nouvelle fonctionnalité, six mois plus tard par quelqu’un d’autre — ou par vous-même, qui aurez tout oublié. Optimiser pour la lecture plutôt que pour l’écriture est donc un choix rationnel, pas un caprice de perfectionniste.
Le clean code ne ralentit pas non plus le développement à long terme. Un code confus finit par accumuler ce qu’on appelle la dette technique : chaque modification devient plus risquée et plus lente. Écrire clairement dès le départ, c’est investir un peu de temps maintenant pour en gagner beaucoup plus tard.
Le nommage : la première forme de documentation
Un bon nom rend un commentaire inutile. Les noms de variables, de fonctions et de classes doivent révéler leur intention : ce qu’ils contiennent ou ce qu’ils font, pas comment ils le font.
// Avant : que représentent ces variables ?
const d = 86400000;
const l = users.filter((u) => u.a > 18);
// Après : le code se lit comme une phrase
const MILLISECONDES_PAR_JOUR = 86400000;
const utilisateursMajeurs = users.filter((user) => user.age > 18);
Quelques repères utiles : préférez des noms prononçables et cherchables (MILLISECONDES_PAR_JOUR se retrouve à la recherche, d non) ; évitez les abréviations obscures ; pour une fonction, commencez par un verbe (calculerTotal, envoyerEmail). Le gain est immédiat : le lecteur comprend sans effort.
Des fonctions courtes qui font une seule chose
Une fonction devrait faire une seule chose, et la faire bien. Quand une fonction dépasse une vingtaine de lignes ou enchaîne plusieurs responsabilités, elle devient difficile à tester et à réutiliser. La découper en sous-fonctions au nom explicite clarifie le tout.
// Avant : une fonction qui fait tout
function traiterCommande(commande) {
// valider
if (!commande.articles || commande.articles.length === 0) {
throw new Error("Commande vide");
}
// calculer le total
let total = 0;
for (const article of commande.articles) {
total += article.prix * article.quantite;
}
// appliquer une remise
if (total > 100) total *= 0.9;
// enregistrer
db.save({ ...commande, total });
return total;
}
// Après : chaque étape a un nom, la logique se lit d'un coup d'œil
function traiterCommande(commande) {
validerCommande(commande);
const total = appliquerRemise(calculerTotal(commande.articles));
enregistrerCommande(commande, total);
return total;
}
function validerCommande(commande) {
if (!commande.articles?.length) {
throw new Error("Commande vide");
}
}
function calculerTotal(articles) {
return articles.reduce((somme, a) => somme + a.prix * a.quantite, 0);
}
function appliquerRemise(total) {
return total > 100 ? total * 0.9 : total;
}
La version « après » est plus longue en nombre de lignes, mais chaque fonction se comprend isolément et se teste séparément. C’est un compromis presque toujours gagnant.
DRY, KISS, YAGNI : trois principes phares
Trois acronymes reviennent constamment dans les discussions sur la qualité du code.
DRY (Don’t Repeat Yourself) invite à ne pas dupliquer la logique. Si la même règle métier est copiée à trois endroits, une correction devra être faite trois fois — et on en oubliera une. On factorise dans une fonction unique.
KISS (Keep It Simple, Stupid) rappelle que la solution la plus simple qui fonctionne est généralement la meilleure. Une abstraction sophistiquée impressionne, mais un code direct se maintient mieux.
YAGNI (You Aren’t Gonna Need It) met en garde contre l’anticipation excessive. On code ce dont on a besoin maintenant, pas ce dont on pourrait avoir besoin un jour. Les fonctionnalités « au cas où » alourdissent le code sans jamais servir.
Attention à la sur-application de DRY : deux morceaux de code qui se ressemblent aujourd’hui ne partagent pas forcément la même raison de changer. Les fusionner prématurément crée un couplage artificiel qu’il faudra douloureusement défaire quand les deux cas divergeront. Un peu de duplication vaut parfois mieux qu’une mauvaise abstraction.
Des commentaires qui expliquent le « pourquoi »
Un bon commentaire n’explique pas ce que fait le code — le code devrait le dire lui-même — mais pourquoi il le fait ainsi. Le contexte, la contrainte métier, la raison d’un choix contre-intuitif : voilà ce qui mérite un commentaire.
// Commentaire inutile : il paraphrase le code
i = i + 1; // on incrémente i
// Commentaire utile : il donne le contexte invisible
// L'API du prestataire limite à 50 requêtes/minute ;
// on temporise pour éviter le blocage (erreur 429).
await attendre(1200);
Méfiez-vous des commentaires : ils mentent avec le temps. Quand le code change et que le commentaire reste, il devient trompeur. Le meilleur commentaire est souvent celui qu’on peut supprimer en rendant le code plus clair (un nom parlant, une constante nommée).
Une gestion d’erreurs explicite
Ignorer les erreurs est une source majeure de bugs difficiles à diagnostiquer. Un catch vide masque un problème au lieu de le traiter. Le clean code rend les erreurs visibles et les gère de façon intentionnelle.
// Avant : l'erreur est avalée en silence
try {
const data = await recupererProfil(id);
afficher(data);
} catch (e) {}
// Après : on distingue les cas et on informe
try {
const data = await recupererProfil(id);
afficher(data);
} catch (erreur) {
if (erreur.status === 404) {
afficherMessage("Profil introuvable.");
} else {
journaliser(erreur);
afficherMessage("Une erreur est survenue, réessayez.");
}
}
Préférez lever une erreur claire tôt (« échouer vite ») plutôt que de laisser une valeur invalide se propager et provoquer un plantage obscur dix étapes plus loin.
Le clean code n’est pas un dogme
C’est le point le plus important, et souvent le plus oublié. Les principes ci-dessus sont des guides, pas des lois. Les appliquer aveuglément peut nuire autant que les ignorer.
Découper à l’excès en micro-fonctions peut fragmenter la logique au point qu’on doive sauter entre dix endroits pour suivre un traitement. Poursuivre DRY jusqu’à l’absurde produit des abstractions générales que personne ne comprend. Renommer sans fin au nom de la « pureté » fait perdre du temps sans valeur ajoutée. Le bon développeur ajuste selon le contexte : la taille de l’équipe, la durée de vie du projet, la criticité du code.
La vraie boussole est simple : le prochain développeur comprendra-t-il facilement ce code ? Si oui, il est probablement assez propre. Si non, aucun respect scrupuleux des règles ne le sauvera. Le clean code sert la lisibilité ; quand une « règle » dégrade la lisibilité, c’est la règle qu’on abandonne, pas la lisibilité.
Intégrer ces principes au quotidien
Adopter le clean code se fait progressivement, pas d’un coup. La règle du boy-scout résume bien l’esprit : laissez le code un peu plus propre que vous ne l’avez trouvé. À chaque passage, un nom clarifié, une fonction découpée, un commentaire obsolète supprimé. La revue de code entre pairs accélère aussi l’apprentissage, en confrontant les points de vue sur ce qui est lisible.
Ces habitudes s’appuient enfin sur un bon usage du contrôle de version, pour isoler chaque amélioration dans des commits clairs. Nos commandes Git essentielles constituent le compagnon naturel d’une démarche de qualité : un historique propre est, lui aussi, une forme de code propre.
Écrire du code lisible est une compétence qui se cultive, pas un talent inné. Avec ces principes en tête — et le recul nécessaire pour ne pas en faire une religion — vous produirez un code dont vos collègues, et votre futur vous, vous seront reconnaissants.