Le Clean Code nous vient de Robert Cecil Martin, qui a inventé ce terme dans son livre « Clean Code: Ra­fac­to­ring, Patterns, Testen und Techniken für sauberen Code » pour décrire un code écrit de façon propre. Les principes du Clean Code sont toutefois nettement plus anciens et ne trouvent pas leur origine dans le dé­ve­lop­pe­ment logiciel. Nous vous ex­pli­quons ce qui distingue un code propre, quels sont ses avantages et comment vous pouvez écrire du Clean Code.

Le Clean Code, c’est quoi ?

Le Clean Code n’est pas un ensemble de règles strictes mais désigne plutôt une série de principes pour produire un code com­pré­hen­sible de façon intuitive et facile à modifier. Com­pré­hen­sible signifie dans ce cas un code im­mé­dia­te­ment in­tel­li­gible par n’importe quel dé­ve­lop­peur qualifié. Les ca­rac­té­ris­tiques suivantes aug­men­tent la li­si­bi­lité du Clean Code :

  • Le processus d’exécution de l’ensemble de l’ap­pli­ca­tion est logique et structuré de façon simple.
  • Le rapport entre les dif­fé­rentes parties du code est trans­pa­rent.
  • La tâche ou le rôle de chaque classe, fonction, méthode et variable est im­mé­dia­te­ment com­pré­hen­sible.

Un code est facile à modifier lorsqu’il peut être fa­ci­le­ment ajusté et complété. À l’inverse, il est également plus simple de corriger les erreurs dans le code. Par con­sé­quent, le Clean Code est très facile à en­tre­te­nir. Un code fa­ci­le­ment mo­di­fiable comporte les attributs suivants :

  • Les classes et les méthodes sont petites et, dans la mesure du possible, ont une seule et unique tâche.
  • Les classes et les méthodes sont pré­vi­sibles, fonc­tion­nent de la façon attendue et sont ac­ces­sibles au grand public grâce à des API bien do­cu­men­tées (in­ter­faces).
  • Le code dispose de tests d'unité.

Les avantages d’une telle pro­gram­ma­tion sont évidents : le Clean Code n’est pas dépendant du dé­ve­lop­peur initial. En principe, n’importe quel pro­gram­meur peut ainsi tra­vail­ler avec un tel code. Ceci permet par exemple d’éviter les problèmes survenant lorsque l’on travaille avec un legacy code. L’entretien du logiciel s’en trouve également facilité puisque les bugs peuvent être trouvés et corrigés fa­ci­le­ment.

Aperçu des principes du Clean Code

Mais comment écrire un code propre ? Pour écrire du Clean Code, il convient de respecter certains principes de base de la pro­gram­ma­tion. Ce ne sont pas des ins­truc­tions concrètes sur la façon de pro­gram­mer tel élément dans telle situation mais plutôt une vision réfléchie du travail d’un dé­ve­lop­peur. Ceci explique pourquoi les dé­ve­lop­peurs de la com­mu­nauté ont une vision dif­fé­rente de ce qu’est un Clean Code : certains pro­gram­meurs pourront con­si­dé­rer un code comme « clean » et d’autres non. Dé­ter­mi­ner à quel point un code est clean est toujours un peu subjectif. Nous vous pré­sen­tons ci-après plusieurs principes établis du Clean Code qui sont reconnus par la plupart des dé­ve­lop­peurs.

Un code aussi simple que possible : KISS

KISS (Keep it simple, stupid) est l’un des plus anciens principes du Clean Code. Il fut appliqué par l’armée amé­ri­caine dès les années 1960. KISS rappelle aux pro­gram­meurs de cons­truire leur code de façon aussi simple que possible. Toute com­plexité inutile doit être évitée. En pro­gram­ma­tion, il n’y a jamais une seule méthode pour résoudre un problème. Une tâche peut toujours être exprimée dans dif­fé­rents langages et formulée avec dif­fé­rentes commandes. Par con­sé­quent, les pro­gram­meurs observant le principe KISS doivent cons­tam­ment se demander s’ils ne peuvent pas résoudre un problème plus fa­ci­le­ment.

Éviter les ré­pé­ti­tions inutiles : DRY

DRY (Don’t repeat yourself) est en quelque sorte la con­cré­ti­sa­tion du principe KISS. Un Clean Code res­pec­tant ce principe implique que chaque fonc­tion­na­lité doit avoir une seule et unique re­pré­sen­ta­tion au sein du système global.

Note

Le contraire de DRY est WET (We enjoy typing). On appelle WET un code com­por­tant des ré­pé­ti­tions inutiles.

L’exemple suivant illustre le principe d’un Clean Code DRY : le nom d’uti­li­sa­teur et le mot de passe sont appelés à deux reprises dans le code afin d’être utilisés pour dif­fé­rentes actions. Au lieu de pro­gram­mer les deux processus sé­pa­ré­ment, ils peuvent être ras­sem­blés dans une même fonc­tion­na­lité. Ceci permet de trans­for­mer un code WET (« humide ») com­por­tant des ré­pé­ti­tions en code DRY (« sec »).

Code WET :

//Variante A
let username = getUserName();
let password= getPassword();
let user = { username, password};
client.post(user).then(/*Variante A*/);
//Variante B
let username = getUserName();
let password= getPassword();
let user = { username, password};
client.get(user).then(/*Variante B*/);

Code DRY :

function getUser(){
    return {
        user:getUserName();
        password:getPassword();
    }
}
//Variante A
client.post(getUser()).then(/*Variante A*/ );
//Variante B
client.get(getUser()).then(/*Variante B*/);

Supprimer ce qui est inutile : YAGNI

Le principe de Clean Code YAGNI (You aren’t gonna need it) exprime l’idée suivante : un dé­ve­lop­peur devrait uni­que­ment ajouter des fonc­tion­na­li­tés sup­plé­men­taires au code lorsqu’elles sont né­ces­saires. Le principe YAGNI est étroi­te­ment lié aux méthodes de dé­ve­lop­pe­ment agile. Au lieu de partir d’un concept global dans le dé­ve­lop­pe­ment, une pro­gram­ma­tion selon le principe YAGNI consiste à élaborer l’ar­chi­tec­ture du logiciel par de petites étapes afin de pouvoir réagir aux problèmes de façon dynamique et ciblée. Par con­sé­quent, un Clean Code est toujours généré lorsque le problème sous-jacent est résolu d’une façon aussi efficace que possible.

La li­si­bi­lité avant la concision

Le code doit être opé­ra­tion­nel et pouvoir être lu par la machine qui l’exécutera. Mais lorsque plusieurs personnes tra­vail­lent sur un même projet, les autres dé­ve­lop­peurs doivent également pouvoir com­prendre le code. C’est pourquoi dans le dé­ve­lop­pe­ment logiciel, la li­si­bi­lité prime toujours sur la concision du code. Écrire un code concis, mais in­com­pré­hen­sible pour les autres dé­ve­lop­peurs n’aurait aucun sens. La dé­no­mi­na­tion de variables constitue un bon exemple de li­si­bi­lité dans un Clean Code.

Un nom de variable doit toujours être com­pré­hen­sible sans in­for­ma­tions com­plé­men­taires. La variable suivante n’est pas com­pré­hen­sible sans con­nais­sances de base ni ex­pli­ca­tions :

int d;

A contrario, le nom suivant, qui désigne la même variable, est évident :

int elapsedTimeinDays;
Aller au menu principal