Ecrire du code propre

Auteur du billet de blog : Nicolas Hilaire - Neotech Solutions

Nicolas Hilaire

Consultant .NET
  Publié le vendredi 24 juin 2016

Artisan logiciel particulièrement intéressé par les technologies .NET. Polyvalent et curieux, je suis néanmoins à l'écoute des autres technologies du marché. MVP (Microsoft Most Valuable Professional) de 2007 à 2014, je suis également auteur d'un ouvrage pour apprendre le C#, à destination des débutants et de plusieurs MOOCs sur le C#, Windows Phone ou ASP.NET MVC...

En février, j’ai eu le plaisir d’écrire un petit article pour le magazine Programmez! (http://www.programmez.com/magazine/programmez-194-pdf) sur comment écrire un code propre. Je vous le mets également ici pour que vous aussi vous puissiez tenter d’écrire un code plus propre. Bonne lecture.

Vous vous êtes déjà retrouvés devant un code illisible ? Un bug que vous devez corriger, ou une fonctionnalité à rajouter, et rien que la lecture du code vous pique les yeux ?

C'est la dure loi de l'écriture de logiciel. Le temps passe ; des fonctionnalités sont ajoutées, des changements sont faits, des corrections par-ci par-là... Les développeurs ont changé d'équipe ou de projet et la moindre modification de code devient de plus en plus risquée et de plus en plus complexe. C’est bien connu, la productivité diminue au fur et à mesure que le temps passe.

Martin Fowler disait que n'importe qui peut écrire du code qu'un ordinateur comprend. Les bons développeurs écrivent du code que les humains peuvent comprendre.

Vous devez donc écrire votre code comme un auteur de livre, faire en sorte qu’il raconte une histoire claire, qu’il soit fluide et auto-descriptif. Il faut qu’un futur relecteur comprenne très rapidement l’intention de votre code et ainsi lui faciliter sa maintenance ou ses évolutions.

Je tiens à vous dire tout de suite qu’écrire un code propre est compliqué. Cela demande peu de connaissances, mais beaucoup d'entraînement. Mais si vous n’avez pas encore tourné la page, c’est que vous avez envie de vous améliorer et c’est un très bon point.

Alors, comment améliorer la lisibilité de son code ? Vous trouverez dans cet article quelques bons principes éprouvés qui pourront faire de vous un meilleur auteur de code.

Pour la suite des exemples, j’utiliserai le C#, langage que j’apprécie particulièrement, mais les conseils valent pour n’importe quel langage.

Un nommage significatif :

Exprimer l’intention

Cela parait évident, mais utilisez des noms qui expriment l’intention, qu’il s’agisse de variables, de méthodes ou de classes.

Pourquoi écririons-nous le code suivant :

alors que nous pourrions directement écrire :

Ainsi, toute utilisation future d’une de ces deux variables indiquera bien avec quelle adresse nous travaillons.

C’est cela, exprimer l’intention de la variable. Et c’est parfois très complexe.

Ne pas utiliser de nombre ou chaîne magique

De la même façon, si je tombe sur la méthode suivante, je ne suis pas sûr de comprendre vraiment ce qu’elle fait :

On se doute bien qu’on cherche un truc aléatoirement dans des tableaux … mais quoi ? C’est quoi ce 53 ? Et ce “R” ?

N’est-ce pas plus clair avec un nommage plus adapté de ce genre ?

Les nombres magiques dans le code sont une vraie plaie. C’est une très bonne pratique de les remplacer par des constantes aux noms bien explicites. Bien sûr, on pourrait rajouter un commentaire à côté, mais c’est tellement plus clair quand la variable est bien nommée.

Évitez les noms fourre-tout

Soignez avec attention le nom de vos classes. Évitez les noms fourre-tout comme Manager, Processor, Provider, Service, etc. Oui - je sais - vous l’avez déjà fait ! Une classe doit être un nom, et sûrement pas un verbe.

 

Vous gagnerez aussi à faire en sorte que vos noms puissent se chercher facilement dans le code avec un Control+F. Les éditeurs sont de plus en plus habiles pour naviguer dans le code, mais une bonne vieille recherche textuelle peut parfois vous sauver la vie.

Pas de notation hongroise

Par pitié, enlevez-moi tous les préfixes de la notation hongroise https://fr.wikipedia.org/wiki/Notation_hongroise qui ne servent à rien quand on a un IDE digne de ce nom !

C’est quand même évident que c’est un entier. Ça avait peut-être un sens en 1960 … mais là, on est en 2016 ! Et puis en cas de doute, il y a toujours l’info-bulle pour nous rappeler de quel type est la variable :

Remplacer les commentaires par des méthodes bien nommées

Avec un bon nommage de vos méthodes, vous pouvez aussi remplacer des potentiels commentaires par des noms de méthodes explicites, voyez par exemple :

Il suffit d’extraire les conditions des tests et d’utiliser le commentaire pour nommer la méthode :

C’est tout de même beaucoup plus lisible, non ?

Découpez votre code

Des méthodes ou des classes doivent bien sûr être correctement nommées, mais elles ne doivent pas contenir trop de code. Quand une méthode est trop longue, il faut la découper en plusieurs méthodes. C’est un peu ce que nous avons fait juste au-dessus.

 

Idéalement, chaque méthode ne doit faire qu’une seule chose (et doit le faire bien !). Par exemple vous pouvez changer un code de ce genre :

par :

Bien découper une grosse méthode en plusieurs petites permet également de mieux exprimer l’intention de votre code en faisant apparaître un algorithme explicite :

Cependant, lorsque vous découpez vos méthodes (ou que vous en créez), prenez garde aux paramètres. Un relecteur de code va s’attendre à ce que les paramètres d’une méthode soient des paramètres d’entrée. Les paramètres de sortie sont plus difficiles à appréhender. Si vous devez modifier quelque chose dans la méthode, faites en sorte de renvoyer une valeur.

De même, n’utilisez pas de booléen en paramètre d’une méthode. Ils sous-entendent que la méthode fait 2 choses différentes ; une quand le booléen vaut vrai, une autre chose quand il est égal à faux.

Plutôt que :

Faites deux méthodes FaitCeci() et FaitCela() et utilisez les indépendamment.

Et puis que diriez-vous d’une méthode comme celle-ci, que l’on retrouve dans beaucoup de frameworks ?

Alors elle fait quoi ? Un mode append, un mode overwrite ? les deux ? Encodage par défaut ? Bref, on n’en sait rien tant qu’on ne va pas voir la documentation !

 

Vos classes aussi ne doivent faire qu’une seule chose, et pour cela n’hésitez pas à suivre le principe de responsabilité unique https://fr.wikipedia.org/wiki/Principe_de_responsabilit%C3%A9_unique que l’on retrouve dans les principes SOLID (https://fr.wikipedia.org/wiki/SOLID_(informatique)).

 

Ce principe de responsabilité unique vient souvent avec un autre principe, à savoir qu’une classe doit être ouverte à l’extension et fermée à la modification (https://fr.wikipedia.org/wiki/Principe_ouvert/ferm%C3%A9)

 

Et évidemment, factoriser le code qui est identique. Suivez le principe DRY https://fr.wikipedia.org/wiki/Ne_vous_r%C3%A9p%C3%A9tez_pas. Oui, - je sais - comme vous, ça m’est déjà arrivé de faire un copier-coller plutôt qu’un refactoring adéquat. Honte à moi.

Bien commenter

Un commentaire utile est un commentaire absent. Si le code est auto-descriptif, alors il n’y a pas besoin de commentaire. Quand vous êtes tentés d’écrire un commentaire pour clarifier votre code, voyez plutôt s’il n’aurait pas besoin d’un petit refactoring pour le rendre plus lisible.

 

Comme on l’a déjà vu, qu’est-ce qui est le plus clair ?

ou

Bien sûr, bannissez les commentaires inutiles et redondants :

La classe et ses propriétés sont suffisamment bien nommées pour ne pas avoir à répéter un commentaire redondant qui vient polluer le code et sa lisibilité.

Et ne me faites pas croire que vous n’avez jamais écrit un commentaire de ce genre, je ne vous croirai pas :).

 

Je ne dis bien sûr pas qu’il ne faut pas commenter son code, mais soyez certains que votre commentaire apporte quelque chose et qu’il clarifie bien votre intention ou pourquoi vous avez choisi telle solution plutôt qu’une autre. Par exemple :

Enfin, et cela sera mon dernier mot sur les commentaires : ne laissez pas du code en commentaire. Non, ne le faites pas, c’est mal ! Si je viens à travailler sur le même code que vous, je vais me demander pourquoi le code est en commentaire. Est-ce que je dois le supprimer ? Mais s’il n’est pas supprimé, c’est que le code est important ? Oui ? Alors pourquoi est-il commenté ? Si c’est juste pour garder une trace, le contrôle de code source est fait pour ça !

Conclusion

On pourrait parler de propreté de code pendant des pages et des pages. Certains l’ont fait. Si le sujet vous intéresse, je ne peux que vous encourager à lire l’excellent livre de Robert C. Martin “Clean Code”, ou sa traduction en français “Coder proprement”, livre que tout développeur devrait avoir lu. Il y a un principe intéressant que vous pouvez commencer à appliquer dès maintenant : le principe du boy scout. “Après votre passage, laissez toujours un code plus propre que vous ne l’avez trouvé”. Pensez-y la prochaine fois.

 

Et comme le disait Martin Golding, écrivez votre code comme si la personne qui allait devoir le maintenir était un psychopathe violent qui sait où vous habitez.