Clean code
Clean code: A Handbook of Agile Software Craftsmanship
Clean code est un livre que tous les développeurs devraient lire. Et je pèse mes mots.
Étrangement, il ne m’a pas transcendé pendant la lecture elle-même. En fait, j’avais l’impression que l’auteur ne m’apprenait pas forcément grand chose. En tant que développeur, vous voyez du code toute la journée, vous savez dinstinguer un code source pourri d’un bon code.
Le truc, c’est que cette lecture mûrit. Et une fois devant un fichier source, on ne peut s’empêcher de repenser à ce bouquin. On se rend compte qu’à tel endroit on devrait procéder autrement pour rendre le code plus compréhensible, qu’à tel autre il faudrait renommer une variable etc…
Et surtout, on ne peut plus s’empêcher de mettre son grain de sel.
Un code soigné
Il est assez facile de reconnaitre un code tout pourri, illisible. On repère les paquets de nouilles à des lieues à la ronde. Mais arriver à définir de qui caractérise du code soigné est un exercice plus périlleux.
L’auteur Robert C. Martin propose plusieurs définitions, dont la sienne. Il cite également quelques collègues, et je me permets de reprendre à mon tour une partie de définition qui me semble tomber juste.
Clean code is simple and direct. Clean code reads like well-written prose.
Un code soigné est simple et direct. Il se lit comme de la prose bien écrite.
Grady Booch, author of Object Oriented Analysis and Design with Applications
Suivie par une explication de l’auteur.
Reading clean code will never be quite like reading Lord of the Rings. Still, the literary metaphor is not a bad one. Like a good novel, clean code should clearly expose the tensions
in the problem to be solved. It should build those tensions to a climax and then give the reader that “Aha! Of course!” as the issues and tensions are resolved in the revelation of an obvious solution.
Lire du code soigné ne s’approchera jamais de la lecture du Seigneur des Anneaux. Cependant, la métaphore littéraire n’est pas mauvaise. Comme un bon roman, un code propre devrait clairement révéler le problème à résoudre. Il devrait révéler des tensions jusqu’à un paroxysme et ensuite donner au lecteur ce « Aha ! Bien sûr ! » lorsque les problèmes et tensions sont résolues dans la révélation d’une solution évidente.
Robert C. Martin, Clean Code
The boy scout rule
Si je devais retenir une chose de ce livre, c’est la boy scout rule (règle du boy scout).
Leave the campground cleaner than you found it.
Laisse le campement plus propre que tu l’as trouvé
Chaque fois que vous allez lire du code améliorable (pour ne pas dire pourri), à cause de ce livre et de cette règle vous ne pourrez plus hésiter entre laisser en l’état (si ça marche, on ne touche pas) et changer les choses.
La première solution est la plus facile, mais elle permet à du code pourri de perdurer, elle entretient la dette technique d’un logiciel. C’est la solution conservatrice qui est souvent préférée.
La deuxième solution permet d’améliorer continuellement la compréhensibilité du code source, donc de faciliter sa maintenance et la correction de bugs. Elle est plus risquée, mais se fait sans trop d’arrières pensées si le code est testé. Et s’il ne l’est pas, le fait d’écrire un test entre aussi dans cette catégorie.
Un livre à lire
Je vous passe les détails des différents chapitres abordés par ce livre, chacun couvre un domaine de la propreté du code. On y aborde principalement :
- le nommage des variables, classes et fonctions ;
- le contenu des fonctions, les arguments ;
- les commentaires (dans un sens un peu inattendu mais finalement intéressant) ;
- les objets et structures de données ;
- le formattage du code ;
- les classes, leur taille, organisation et responsabilité ;
- les tests unitaires.
L’auteur nous a tout de même gratifié d’une étude de cas d’un chapitre (chapitre 14) qu’on peut facilement passer. C’est le seul point négatif de ce livre qui se lit quand même globalement très aisément (au final, il y a peu de code).
Malgré cette partie pesante, le livre vaut vraiment le coup. Clean Code est un livre au premier abord anodin mais qui a fait évoluer ma manière de développer. Je ne dis pas que ce que je produits est devenu subitement parfait. Qui peut prétendre à ça ? Mais je pense mieux faire, et j’ai surtout moins de scrupules à intervenir dans du code que je croise au détour d’un débug.
- Clean Code [broché]
- Clean Code [kindle]