Dans cet article, je vous propose une revue du livre Coder Proprement de Robert C. Martin. Ce livre fait partie de ma lecture du mois évoquée dans mes objectifs de 2014 (j’en parle dans l’article Quelles bonnes résolutions prendre pour 2014 ?).

J’en ai également profité pour vous faire une synthèse rapide de différents principes que je trouve importants. A la fin de l’article, vous trouverez également une check-list (à télécharger) qui vous permettra d’améliorer immédiatement la qualité de votre code.

Au début du livre, l’auteur commence par parler de code et explique qu’il y aura toujours du code et donc toujours du code de plus ou moins bonne qualité.

Au fur et à mesure, il développe une idée simple : le développeur n’est pas seulement une personne qui écrit du code pour une machine, mais c’est aussi un auteur qui écrit du code que les autres doivent pouvoir relire et comprendre.

J’ai trouvé ce livre un peu difficile à lire, car l’auteur développe principalement des règles de ce qu’il faut faire ou ne pas faire.

Alors effectivement, c’est règles sont « justes » et logiques, mais ça demande un effort pour arriver au bout… Néanmoins, elles sont intéressantes et je suis bien content d’avoir passé du temps là-dessus. Ce livre m’a appris à mieux comprendre et à appliquer certains principes (OCP, SRP…).

Les principes à retenir pour coder proprement

Suite à la lecture de ce livre, je vous ai préparé une liste de règles que vous pouvez appliquer immédiatement à votre code. J’ai choisi des règles qui me semblent importantes, mais bien sûr, je n’ai pas extrait toutes les règles dont il parle dans son livre Coder Proprement.

Utiliser des noms significatifs

L’idée qui apparaît est tout simplement qu’il faut bien nommer ses variables, ses classes et ses méthodes.

Cela peut sembler évident et pourtant je pense que cette étape est difficile. Je vois souvent du code avec des noms du genre « Manager ». Mais au final, qu’est-ce qu’un manager ? Que fait-il vraiment dans le code ?

Cette règle énonce donc qu’il faut réfléchir aux noms. Un peu comme pour un bébé : prenez le temps de la réflexion, car le nom va rester durant toute la vie du projet 🙂

Une manière simple de trouver un bon nom est de chercher à définir l’intention d’une variable ou d’une méthode. Il faut que la lecture de son nom puisse immédiatement nous dire ce qu’elle fait dans le code.

Avoir des fonctions courtes

Cette règle est aussi simple à mettre en oeuvre et pourtant je vois souvent des fonctions énormes.

Quelle est la définition de courte ? Et bien d’après l’auteur, il faut écrire des fonctions qui font une seule chose.
Sur ce point, je suis d’accord avec lui à 100%. La responsabilité unique est un bon principe à respecter.

J’en ai d’ailleurs déjà parlé dans l’article Concevoir des applications SOLID avec SRP (Single Responsibility Principle).

Des commentaires pour compléter le code

L’auteur exprime son point de vue sur les commentaires et il faut dire que je n’étais pas tout à faire d’accord avec lui.

Selon Robert C Martin, il faut commenter uniquement le code qui en a vraiment besoin.

C’est vrai que j’ai l’habitude d’écrire beaucoup de commentaires et après la lecture de ce chapitre, je me suis rendu compte qu’il y a probablement des lignes qui ne servent à rien.

La règle énonce donc que les commentaires doivent être écrits uniquement s’ils permettent de comprendre du code (c’est-à-dire que si vous supprimez le commentaire, il faudra sûrement plusieurs minutes pour comprendre le code, alors oui le commentaire à du sens).

Les choses évidentes comme « cette fonction retourne un utilisateur » ne sont pas très utiles selon lui.

Ecrire comme dans un journal

Cette règle prend tout son sens quand on repense au fait que le dévelopeur est aussi un auteur. Selon Robert C. Martin, il faut écrire du code comme dans un journal avec une suite d’articles.

Chaque article (=une fonction) fait référence à un article suivant (=une autre fonction).

Ainsi, votre code sera composé d’une série d’articles qui se suivent.

Utiliser les exceptions à la place des codes de retour

Cette règle se base sur un principe simple : utiliser des codes de retour est souvent source d’erreurs, car les développeurs ne les vérifient pas forcément.
De plus, les codes de retour obligent à écrire des conditions supplémentaires dans le code (if … else). Cela va donc compliquer un algorithme et en réduire sa lisibilité.

Les exceptions sont des mécanismes qui ont été crées pour gérer les erreurs, autant donc les utiliser.

Les tests unitaires doivent être aussi propres que le code de production

Etant donné qu’il va falloir maintenir les tests unitaires, il est donc logique que ces tests doivent être rédigés de manière propre comme s’il s’agissait de code que vous allez mettre en production.

Pour écrire des tests, Robert C. Martin indique qu’il faut respecter l’acronyme FIRST :

• Fast (Rapide) : Les tests doivent être rapides pour qu’ils soient lancés régulièrement,
• Independant (Indépendant) : Les tests doivent pouvoir être lancés dans n’importe quel ordre,
• Repeatable (Reproductible) : Les tests doivent pouvoir être reproduits dans n’importe quel environnement (votre poste de dev, la recette ou même la production si nécessaire),
  Self-Validating (Auto validant) : Les tests doivent avoir un résultat binaire (succès ou échec),
• Timely (Au moment opportun) : Les tests doivent être écrits juste avant le code de production. Si vous écrivez les tests après, vous remarquerez qu’il sera assez difficile de tester le code de production.

Toujours écrire de petites classes

La taille d’une classe doit toujours être égale à 1. Mais un quoi ? Quelle est l’unité ? En fait, l’unité est la responsabilité. Chaque classe doit donc avoir une seule responsabilité.
Respectez toujours le principe SRP (Single Responsibility Principle).

Il donne une astuce : une classe courte doit pouvoir être décrite en 25 mots environ sans utiliser « si », « et », « ou » et « mais ». Cette astuce fonctionne vraiment (je l’ai essayé).

Il donne également un autre indicateur intéressant : créer des classes fortement cohésives.
Une forte cohésion indique simplement que les méthodes de votre classe manipulent en grande partie les membres de votre classe.

Créer des classes évolutives

Ecrire une classe de taille réduire avec une forte cohésion est déjà une bonne chose. Mais si en plus, vous arrivez à prévoir des mécanismes d’extensibilité alors votre classe pourra être facilement réutilisée.

L’auteur indique qu’il faut toujours penser à écrire du code extensible (par exemple soit par héritage ou par des mécanismes comme les délégates ou les évents) dans l’objectif de respecter le principe d’Ouvert Fermé (OCP).
Cela vous permettra d’ajouter des comportements sans modifier le code de votre classe.

Séparer la construction d’un système et son utilisation

L’auteur conseille de toujours séparer la partie création des instances et la partie utilisation. L’objectif étant de réduire le couplage et de faciliter les évolutions.
Une manière simple pour y arriver est d’utiliser l’injection des dépendances et un contrôleur d’IoC.
Sur ce point je suis tout à fait d’accord avec lui et c’est bien ce que je recommande également dans mes formations.

Plan d’action

Je vous ai préparé une check-list que vous pouvez utiliser pour vérifier et améliorer la qualité de votre code. Elle est basée sur certains de ces principes et donne également des indications sur les démarches à suivre (comment faire).

Pour télécharger cette check-list gratuitement, il suffit de débloquer votre bonus en cliquant sur Like ou J’aime dans la boite ci-dessous.

[sociallocker] Merci de votre partage. Vous pouvez télécharger votre bonus :

Télécharger la check-list
[/sociallocker]