Clean Code : du code pour les humains

Le travail du développeur consiste à écrire du code compréhensible par des machines.
Mais dans le monde de l’industrie être compris par les machines ne suffit pas : dans l’immense majorité des projets sur lesquels nous intervenons, un même code source est manipulé par plusieurs personnes. C’est là que tout se complique car se faire comprendre par des humains n’est pas aussi facile que de se faire comprendre par des machines.

Pour qu’une application puisse évoluer correctement il faut que le code de celle-ci puisse être adapté par n’importe quel développeur. Si ce n’est pas le cas, le coût pour faire évoluer l’application va augmenter exponentiellement avec le temps. C’est là qu’on peut faire une distinction entre le code efficace et le code propre (clean).

Mesurer la lisibilité du code

Comment déterminer si un code est clean ? Ou plutôt à quel point un code est clean ?
Instinctivement on pense à Sonar (en tout cas dans le monde Java) qui donne des mesures sur la complexité, la vulnérabilité, la couverture de test du code. Mais un outil informatisé ne peut pas déterminer à quel point le code sera compréhensible par un autre développeur.
Le meilleur indicateur pour cela, c’est le WTF/M :

The only valid measurement of code quality: WTFs/minutes (source: osnews.com)

Au-delà du mème, l’illustration montre le but recherché par le clean coder : faire diminuer le taux de WTFs/Minutes c’est-à-dire augmenter la lisibilité de son code.

Clean code : le livre

Comment établir des normes pour le clean code ? Certaines pointures du développement logiciel ont essayé de répondre à cette question. Une des plus célèbres, Robert C. Martin (alias Uncle Bob), s’est penché sur les principes qui définissent un code source de qualité dans son livre « Clean Code: A Handbook of Agile Software Craftsmanship ».

ISBN : 9780136083238

Les principes de programmation énoncés dans ce livre ne sont pas des règles à appliquer strictement, il faut les considérer plutôt comme des aides ou des inspirations.

Clean code: les principes

Les principes développés dans ce livre sont des principes généraux, agnostiques du langage de programmation utilisé.

• Le code doit être simple : C’est la première caractéristique du clean code. Il faut éviter autant que possible de complexifier le code en se demandant si la solution implémentée est la plus simple pour répondre au besoin. Plus le code est simple plus il est lisible, plus il sera maintenable dans le futur ; il y a un acronyme qui nous aide à nous rappeler ce principe : KISS (Keep It Simple Stupid).
  Pour cela il convient d’éviter la sur-configurabilité et de proscrire tout ce qui est écrit « au cas où ».

• Le code doit être ciblé (focused) : Un bout de code doit être écrit pour résoudre une et une seule problématique. C’est valable à tous les niveaux d’abstraction du code : méthode, classe, package ou module. Le travail de réflexion autour du découpage du code doit permettre de déterminer les bonnes abstractions*, ainsi les responsabilités de chaque bout de code seront correctement réparties. On retrouve ici les principes SOLID notamment le “ Single Responsibility Principle”.

• Le code doit être testable : Si le code est simple et n’a qu’une seule responsabilité il devrait être facile à tester. Les tests constituent une sécurité contre les régressions qui peuvent intervenir lors de l’évolution du code. Ils sont également la documentation qui permet aux autres développeurs de comprendre le fonctionnement du code testé. Ils doivent être écrits de préférence avant le code productif (TDD) et être dans la mesure du possible automatisés.
  Encore un acronyme qui caractérise les “clean” tests : FIRST (Fast, Independent, Repeatable, Self-Validating, Timely).

* Bad abstraction is worse than duplication : deux bouts de codes peuvent être identiques, s’ils représentent des concepts différents il vaut mieux conserver cette duplication « accidentelle ». Dans ce cas le principe DRY (Don’t Repeat Yourself) ne s’applique pas.

Les principes du Clean Code sont très nombreux et couvrent toutes les phases de la programmation :

• Le nommage des fichiers, des classes, des méthodes et des variables
• Le design des fonctions
• Le traitement des erreurs
• Les tests
• Les commentaires (à limiter au maximum)
• Le formatage du code
• Les logs

Vous en trouverez un florilège ici.

Le but de cet article n’est pas de tous les lister et/ou les résumer mais plutôt de dire à ceux qui peuvent passer des heures à chercher le meilleur nom pour une classe qu’ils pourront trouver des guidelines dans ce livre.

Vous vous souvenez de la deuxième loi de la thermodynamique ? Lorsqu’un système évolue l’entropie augmente inévitablement. C’est pareil pour les systèmes d’information : lorsqu’on adapte le code source d’une application, il est toujours plus dur de ne pas complexifier le code que d’implémenter l’évolution elle-même. Autrement dit, plus le système évolue plus il difficile à maintenir.
« Clean Code » nous invite à combattre l’entropie en proposant des normes pour que le code soit compréhensible par les humains qui le feront évoluer après nous.

Benoît.