Qu'appelle-t-on exactement un code "clean" ?

Le terme "clean code" a été inventé par Robert Cecil Martin (aussi connu sous le pseudonyme Uncle Bob). Il a rédigé un livre éponyme Clean Code: A Handbook of Agile Software Craftsmanship dans lequel il recense toutes les bonnes pratiques qui ont émergé de ses nombreuses années d'expérience. Mais qu'est-ce qui rend un code "bon" ou "mauvais" ?

N'importe quel développeur peut écrire du code qui fonctionne. Un code qui répond aux exigences fonctionnelles. Ce code est-il bon pour autant ? Il est extrêmement important de garder en tête que le code que tu écris est avant tout fait pour être lu par d'autres développeurs (cet autre développeur pouvant même être toi, plusieurs semaines/mois/années plus tard). En ce sens, un bon code est un code qui répond aux besoins fonctionnels tout en étant facilement compréhensible et ouvert aux évolutions par les autres membres de l'équipe.

Pour ce faire, tu dois avoir en permanence en tête les bonnes pratiques, et comprendre pourquoi ce sont des bonnes pratiques. Avec le temps et l'expérience, ça devient une seconde nature.

La notion de "clean code" n'a pas de sens intrinsèque. Elle s'inscrit forcément dans un contexte donné.

Quand tu écris du code, tu dépenses du temps, et comme tu le sais le temps, c'est de l'argent. Écrire du code "coûte" donc de l'argent. En retour, l'objectif est que ce code apporte de la valeur au client final, grâce à l'implémentation d'une nouvelle fonctionnalité par exemple.

En ce sens, écrire du code consiste à avoir toujours en tête la balance entre coût nécessaire à l'écriture du code et valeur ajoutée par ce code. Si cette balance penche plus du côté de la valeur, alors le code peut être considéré "clean" quand bien même il ne respecterait pas toutes les bonnes pratiques.

Prenons un exemple concret. Il existe un peu partout sur le web des concours de programmation dont le seul but est d'arriver le plus rapidement possible à résoudre un problème. Le code que l'on écrit est seulement destiné à être interprété par l'ordinateur, pour vérifier que l'exercice est bon. Autrement dit, le code n'est pas destiné à être lu par d'autres développeurs et il cesse d'apporter de la valeur une fois le concours terminé. L'énoncé est simple et célèbre : l'exercice Fizz Buzz. Voici les règles :

Faire un programme qui renvoie un tableau d'entier de 1 à n dans lequel le nombre est remplacé par "Fizz" si ce nombre est divisible par 3, par "Buzz" si le nombre est divisible par 5 et par "FizzBuzz" si le nombre est à la fois divisible par 3 et par 5

Exemple :

Si l'on doit écrire un code qui se contente de répondre à ce problème avant d'être jeté, on pourrait écrire quelque chose du style :

C'est cours, c'est concis, est-ce que ça en fait un code "clean" pour autant ? Et bien dans le contexte oui tout à fait, ce code bien que pas forcément évident à comprendre au premier coup d'œil a été écrit rapidement pour une grande valeur apportée puisqu'il répond directement au problème. Comme personne ne va plus jamais revenir dessus, ça suffit amplement !

Attention cependant !

Il est tentant du coup de se dire : "ce code, je suis sûr qu'il va être utilisé que très peu de temps, et qu'il n'aura besoin d'aucune modification, donc je peux y aller en mode quick & dirty". Bien souvent, un code va vivre plus longtemps que prévu et devra donc subir des modifications à un moment ou un autre.

Il est donc important de garder en tête les bonnes pratiques que l'on va aborder prochainement pour arriver à produire un code modulable et pérenne !