Près de dix ans après The Pragmatic Programmer, Clean Code est le livre qui a donné un second souffle au mouvement Software Craftsmanship. Tout comme son prédecesseur, c’est une bible pour développeur. J’ai dévoré ce livre du début à la fin et je pense que c’est un livre à relire régulièrement afin de ne pas perdre de vue le bon sens qu’il contient.

Il a été écrit par Robert C. Martin, alias “Uncle Bob”, expert mondialement reconnu dans le domaine des technologies objets. Il est aussi le fondateur et président de Object Mentor, Inc., une équipe d’experts mondiaux dans les domaines C++, Java, C#, Ruby, OO, Design Pattern, et autres.

Le but du livre est de recenser les bonnes pratiques et les expériences d’experts d’Object Mentor afin d’écrire du code propre, robuste et surtout facilement lisible et compréhensible pour d’autres développeurs. La plupart des chapitres sont écrits par Robert Martin mais il a aussi laissé sa plume à d’autres experts : Tim Ottinger, Michael Feathers, James Grenning, Jeff Langr, Dr Kevin Dean Wampler, Brett L. Schubert.

Chapitre 1 : Présentation du contenu du livre et de la vision de ce qu’est un code propre pour Bjarne Stroustrup, Grady Booch, Dave Thomas, Michael Feathers, Ron Jeffries, Ward Cunningham.

Chapitre 2 : De l’importance du nommage. Il part du principe qu’un développeur passe plus de temps à lire du code qu’à en écrire. Aussi il est important de prendre du temps pour choisir le nom des variables, des fonctions, des classes, etc.

Chapitre 3 : De l’écriture des fonctions. Robert se focalise sur l’écriture de fonctions, notamment en ne leur donner qu’une seule responsabilité (Single Responsability Principle) et en veillant à les garder à un seul niveau d’abstraction.

Chapitre 4 : De l’utilisation des commentaires. Qu’est-ce qui différencie un bon commentaire d’un mauvais. Pourquoi est-ce que l’on trouve plus souvent de mauvais commentaires que des bons. Éliminer sans scrupule les mauvais commentaires.

Chapitre 5 : Du formatage du code. Robert nous présente le formatage vertical (taille d’un fichier, d’une méthode) et le formatage horizontal (longueur des lignes, indentation). Il nous renseigne aussi sur la distance verticale ou comment organiser les méthodes les unes par rapport aux autres, en regroupant les fonctions qui forment un groupe logique.

Chapitre 6 : Objets vs Structures de données. Objet = instance de classe qui porte du code métier. Structure de données = container dont l’unique responsabilité est de mettre à disposition des champs publiques. Quand utiliser les uns ou les autres ? La loi de Demeter, qui fixe certaines règles d’exposition de code, est aussi abordée.

Chapitre 7 : De la gestion d’erreurs, par Michael Feathers. Pourquoi gérer les problèmes par des exceptions plutôt que par des codes de retour. Comment écrire du code propre avec des exceptions sans polluer le code métier.

Chapitre 8 : Des limites, par James Grenning. Comment protéger son code aux limites/interfaces et notamment dans la liaison avec du code tiers.

Chapitre 9 : Des tests unitaires. Robert nous explique pourquoi il utilise le “Test Driven Development” pour écrire du code propre et pourquoi il faut considérer le code de test avec autant d’importance et de soins que du code de production. Enfin comment garder propre le code des tests lui-même.

Chapitre 10 : Des classes, avec Jeff Langr. Comment organiser proprement ses classes, que doit contenir une classe, qu’elle est sa taille raisonnable. De même que les fonctions, le principe de responsabilité unique (SRP) doit s’appliquer aux classes afin de garder un design propre. Enfin, comment protéger ses classes pour qu’elles s’adaptent facilement aux changements.

Chapitre 11 : De la construction de systèmes, par Dr Kevin Dean Wampler. Comment s’organise un système d’objets, comment bien instancier ces derniers. Les divers mécanismes qui permettent de mettre en relation des objets tels que l’injection, les proxies, etc sont évoqués.

Chapitre 12 : De l’émergence du design, par Jeff Langr. Comment obtenir une architecture propre et saine en la faisant émerger naturellement, notamment grâce au TDD. Pour cela, Jeff s’appuie sur ce que Kent Beck décrit comme un design simple : tous les tests passent, le code ne contient pas de duplication, le design décrit l’intention du développeur et minimise le nombre de classes et de méthodes.

Chapitre 13 : De la concurrence, par Brett L. Schubert. Brève introduction à la programmation propre dans du code multithreads. Une description beaucoup plus complète forme l’appendice A.

Chapitre 14, 15 et 16 : Ces chapitres sont trois exemples de refactorisation de code pour les rendre propre. Le chapitre 15 est un exemple pris dans le code du framework JUnit et le chapitre 16 est la réécriture de la classe SerialDate.

Enfin, dans le chapitre 17, Robert reprend le concept des “smells” de Martin Fowler dans Refactoring. Ainsi, ce chapitre est un catalogue de trucs et astuces, d’heuristiques et de bonnes pratiques appliquées par Robert lui-même et ses collègues.