Don’t comment bad code. Rewrite it.

Clean Code Chapitre 4

Les gens qui commentent leur code seraient donc une mauvaise pratique ? J’étais dans le faux tout ce temps ?! C’est tendant d’être aussi binaire en faisant appel à une figure d’autorité, ici Robert C. Martin, auteur du livre Clean Code, pour affirmer sa position. Il existe selon moi une posture bien plus efficace à privilégier vous permettant d’apporter de la valeur dans votre produit, et cela, immédiatement. Ici, je vais me servir des commentaires de code comme exemple.

À la lecture de mon flux RSS, un article de blogue soulève un point souvent mal compris même parmi les vétérans des tests automatisés : est-ce que plusieurs assertion dans un test, c’est mal ? Mon point de vue n’est pas aussi tranché, mais je souhaitais revenir là-dessus.

Utiliser une librairie ou un framework de test ne correspond qu’à l’outil que vous devez prendre en main pour écrire des tests unitaires. Pour bien manier la hache, il est indispensable de connaître la théorie au préalable. Comme dit l’adage bien connu d’Abraham Lincoln : « Que l’on me donne six heures pour couper un arbre, j’en passerai quatre à préparer ma hache.« 

NB: cet article avait été originellement écrite sur mon précédent blogue le 1er janvier 2022. Mais il reste d’actualité.