Pourquoi le code propre ? — Clean Code

On entend parfois que le code va disparaître — que bientôt les machines généreront les programmes à partir de simples spécifications, et que savoir coder deviendra inutile. Robert C. Martin balaie l'argument d'un revers de main : une spécification suffisamment précise pour être exécutée par une machine est du code. Le niveau d'abstraction de nos langages montera encore, mais il y aura toujours, quelque part, quelqu'un pour exprimer les détails avec rigueur. Il y aura toujours du code.

La vraie question n'est donc pas si nous écrirons du code, mais dans quel état nous le laisserons.

Le coût total du désordre

Tout développeur ayant deux ou trois ans de métier a déjà été ralenti par le code en désordre de quelqu'un d'autre — ou par le sien. Au début d'un projet, une équipe avance vite. Puis, insidieusement, chaque modification se met à casser deux ou trois autres choses. Plus aucun changement n'est trivial. Il faut « comprendre » les nœuds existants pour pouvoir en ajouter de nouveaux.

À mesure que le désordre s'accumule, la productivité de l'équipe tend asymptotiquement vers zéro.

La direction réagit de la seule façon qu'elle connaît : ajouter des développeurs. Mais les nouveaux venus ne connaissent pas le design du système ; ils produisent encore plus de désordre, et la productivité s'effondre davantage.

Attention

Martin raconte l'histoire d'une entreprise des années 80 dont l'application phare est devenue si désordonnée que chaque version arrivait plus tard, avec plus de bugs et des temps de chargement plus longs. L'entreprise a fini par couler. C'est le mauvais code qui l'a tuée.

Pourquoi écrit-on du mauvais code ?

Parce qu'on est pressé. Parce que le chef serait fâché qu'on « perde » du temps à nettoyer. Parce qu'on est fatigué de ce module et qu'on veut passer au suivant. On regarde le désordre qu'on vient de créer, on se dit qu'un programme qui marche en désordre vaut mieux que rien, et qu'on reviendra le nettoyer plus tard.

C'est ignorer la loi de LeBlanc :

À retenir

Plus tard est synonyme de jamais (Later equals never).

Le grand redesign salvateur

Vient le jour où l'équipe se rebelle et exige une réécriture complète. La direction finit par céder, et une « équipe de choc » part construire le système rêvé sur une page blanche — pendant que tout le monde maintient l'ancien.

Commence alors une course : le nouveau système doit rattraper toutes les fonctionnalités de l'ancien, qui continue d'évoluer. Cette course peut durer des années. Martin l'a vue durer dix ans. Et le jour où elle s'achève, l'équipe d'origine est partie depuis longtemps, et la nouvelle réclame… une nouvelle réécriture, parce que le système est devenu un désordre à son tour.

La morale est sans appel : garder son code propre n'est pas un luxe, c'est une question de survie professionnelle.

Nous passons notre temps à lire du code

Pourquoi ce désordre nous coûte-t-il si cher ? Parce que l'écriture de code neuf nous oblige à lire constamment le code existant.

Note

Le ratio entre temps passé à lire et temps passé à écrire dépasse largement 10 pour 1. Nous lisons sans cesse l'ancien code pour pouvoir écrire le nouveau.

La conséquence est limpide : puisque nous lisons tant, rendre le code facile à lire rend l'ensemble plus facile à écrire. Il n'y a pas d'échappatoire. On ne peut pas écrire du code sans lire le code environnant. Le code que vous rendez facile à lire vous fait gagner plus de temps qu'il ne vous en coûte.

Qu'est-ce qu'un code propre ?

Martin a posé la question à plusieurs grands noms du métier. Leurs réponses se recoupent étonnamment.

Auteur	Ce qui définit un code propre
Bjarne Stroustrup (créateur du C++)	Élégant et efficace ; une logique directe qui empêche les bugs de se cacher ; des dépendances minimales.
Grady Booch	Se lit comme une prose bien écrite ; reflète clairement l'intention du concepteur.
Dave Thomas	Lisible et augmentable par un autre développeur ; possède des tests.
Michael Feathers	Donne l'impression que quelqu'un s'en est soucié (someone cared).
Ward Cunningham	Chaque routine fait à peu près ce que vous vous attendiez à ce qu'elle fasse.

Le fil conducteur ? Un code propre se lit, révèle son intention, et ne surprend pas. Il fait paraître le langage de programmation comme s'il avait été conçu pour le problème.

Un exemple vaut mille principes

Comparons. Voici un fragment qui « marche », mais qui force le lecteur à deviner :

// Que représentent ces nombres ? Cette liste ?
function calc(d: number[]): number {
	let r = 0;
	for (let i = 0; i < d.length; i++) {
		if (d[i] > 0) {
			r += d[i];
			r += d[i] * 0.2;
		}
	}
	return r;
}

Et la même logique, rendue lisible — sans changer le comportement :

type LigneFacture = { montantHT: number };

const TAUX_TVA = 0.2;

function calculerTotalTTC(lignes: LigneFacture[]): number {
	return lignes
		.filter((ligne) => ligne.montantHT > 0)
		.reduce((total, ligne) => total + ligne.montantHT * (1 + TAUX_TVA), 0);
}

Le second fragment révèle son intention. Les noms racontent l'histoire (calculerTotalTTC, TAUX_TVA), la constante magique 0.2 a un nom, et l'on devine immédiatement ce qui se passe. C'est tout l'enjeu du livre : non pas écrire du code plus « malin », mais du code plus honnête.

Astuce

Un bon test mental : si un collègue lit votre fonction et qu'elle fait exactement ce que son nom promet, ni plus ni moins, vous tenez probablement du code propre.

Nous sommes des auteurs

La balise @author d'une Javadoc nous le rappelle : nous écrivons pour des lecteurs. Vous ne tapez pas du code dans le vide — vous rédigez pour les développeurs qui vous reliront, à commencer par vous-même dans six mois. Un auteur a une responsabilité envers ses lecteurs : celle de se faire comprendre.

La règle du boy-scout

Écrire du code propre ne suffit pas : il faut l'entretenir. La dégradation est lente et progressive. La parade tient en une règle empruntée aux scouts américains :

À retenir

Laissez le terrain plus propre que vous ne l'avez trouvé.

Concrètement : à chaque fois que vous touchez un fichier, améliorez-le un tout petit peu. Renommez une variable obscure. Découpez une fonction trop longue. Supprimez un peu de duplication. Aucune de ces actions ne demande plus de quelques secondes.

Imaginez l'effet si le code s'améliorait — ne serait-ce qu'un peu — à chaque commit. C'est l'opposé exact de l'entropie qui ruine les projets : une amélioration continue, portée par chacun, à chaque passage.

À retenir

Il y aura toujours du code ; la seule question est sa qualité.
Le désordre a un coût composé : il ralentit l'équipe jusqu'à la quasi-paralysie. Plus tard = jamais.
Nous lisons le code bien plus que nous ne l'écrivons (>10:1) — optimisez pour la lecture.
Un code propre révèle son intention, se lit comme une prose et ne surprend pas.
Adoptez la règle du boy-scout : laissez chaque fichier un peu plus propre qu'à votre arrivée.

Dans les chapitres suivants, nous passons de la philosophie à la pratique : les noms, les fonctions, les commentaires, et tout l'outillage concret du code propre.