Clean Code : définition, principes et étapes de mise en place

08 Janvier 2025 14 mn Cindy Vieira
Partager sur :
Le clean code est devenu une référence incontournable dans le développement logiciel, notamment grâce à Robert C. Martin, alias Uncle Bob. Si vous pensez que coder, c’est juste faire en sorte que ça fonctionne, il est temps de revoir votre approche. Un bon code ne doit pas seulement tourner, il doit aussi être lisible, compréhensible et facile à maintenir pour toute l’équipe, pas seulement pour celui qui l’a écrit.

L’idée est simple : un code clair et cohérent permet à n’importe quel développeur de s’y retrouver rapidement, de le modifier sans crainte et de contribuer efficacement au projet. Ça nécessite un peu de discipline, une attention particulière à la simplicité et une volonté d’écrire un code qui respecte certaines bonnes pratiques.

Dans cet article, on va voir ensemble ce qu’est réellement le clean code, ses principes essentiels, comment le mettre en place, les bonnes pratiques de programmation adaptées à JavaScript, ainsi qu’un exemple concret pour vous aider à démarrer. L’objectif ? Vous donner toutes les clés pour écrire du code qui ne se contente pas de fonctionner, mais qui dure dans le temps.

La définition du clean code selon Robert C. Martin

Le Clean Code, c’est un ensemble de pratiques indispensables pour écrire un code source clair, lisible et facile à maintenir. Ces principes ont été formalisés par Robert C. Martin dans son livre « Clean Code: A Handbook of Agile Software Craftsmanship », paru en 2008. Ce livre est une référence majeure dans le développement logiciel et continue encore aujourd'hui d'influencer la communauté de développeurs.

Quand on parle de Clean Code, on ne parle pas juste d’un code qui fonctionne. Ça, c’est le minimum. Un bon code doit pouvoir être compris facilement, même par quelqu’un qui n’était pas là quand vous l’avez écrit. Il doit être simple à lire, intuitif à manipuler et surtout, facile à modifier sans risquer de tout casser. En mettant l’accent sur la clarté, la simplicité et la cohérence, vous facilitez la vie de vos collègues, réduisez les risques d’erreur et vous  gagnez du temps sur le long terme.

Le Clean Code est donc indispensable pour travailler efficacement en équipe et éviter l'augmentation de la dette technique sur votre projet. 

Nous allons maintenant voir ensemble les principes clés qui vous permettront de coder proprement.

Les 10 principes du clean code

Robert C. Martin nous propose un certain nombre de principes à mettre en place pour s’assurer que notre code soit propre (clean) :

  • La lisibilité avant tout

    Un code propre est un code qu’on comprend instantanément, sans effort. La lisibilité passe par des noms explicites pour vos variables, fonctions et classes. Une fonction doit être simple, concise et accomplir une seule tâche. Si elle commence à s’étendre sur plusieurs lignes, découpez-la en sous-fonctions plus petites. Ici, le principe KISS (Keep It Simple, Stupid) s’applique : cherchez toujours la solution la plus simple possible. Un code inutilement complexe est un frein pour vous comme pour vos collègues.

  • Une seule responsabilité par élément

    Chaque élément du code, qu’il s’agisse d’une fonction, d’une classe ou d’un module, doit avoir une seule responsabilité bien définie. Une fonction qui gère plusieurs cas différents ou une classe qui s’occupe de tout devient un problème. Elle perd en lisibilité et devient difficile à maintenir.

    Le découpage est essentiel : il permet de créer des éléments réutilisables, testables et faciles à comprendre. Le principe SOLID SRP (Single Responsibility Principle) garantit que chaque élément fait une seule chose, mais le fasse bien.

  • Évitez la duplication de code

    La répétition de code est un signe clair de problème. Répéter plusieurs fois la même logique complique la maintenance : une modification doit alors être faite partout, ce qui augmente les risques d’erreurs.

    Appliquez le principe DRY (Don’t Repeat Yourself). Extrayez le code dupliqué dans une fonction, une classe ou un module. Cela permet d’avoir un code centralisé, factorisé et maintenable sur le long terme.

  • Écrivez un code léger

    Le principe YAGNI (You Aren’t Gonna Need It) consiste à ne pas écrire du code ou ajouter des fonctionnalités dont vous n’avez pas besoin immédiatement. Anticiper des besoins futurs en ajoutant du code « au cas où » est souvent contre-productif. Cela ajoute de la complexité inutile, complique la maintenance et peut même introduire des bugs.

    Écrivez uniquement ce qui est nécessaire ici et maintenant. Vous aurez le temps d’ajouter des évolutions quand le besoin sera réel.

  • Écrivez un code auto-descriptif

    Un bon code se passe de commentaires inutiles. Si vous devez ajouter un commentaire pour expliquer ce qu’une fonction fait, c’est souvent le signe qu’elle n’est pas assez claire.

    Les commentaires doivent uniquement servir à expliquer le pourquoi d’une décision technique, pas à décrire le comment. Le code doit parler de lui-même grâce à des noms explicites et une structure logique. 

  • Limitez le nombre de paramètres dans les fonctions

    Une fonction avec trop de paramètres devient rapidement illisible. Si vous vous retrouvez avec une longue liste de paramètres, il est temps de regrouper les données dans un objet ou une structure adaptée. Cela simplifie l’appel de la fonction et rend son intention plus claire.

    Un nombre réduit de paramètres facilite aussi les tests et limite les erreurs.

  • Simplifiez vos conditions

    Les conditions complexes et imbriquées nuisent à la lisibilité. Plus il y a de conditions, plus le risque d’erreur augmente. Utilisez des garde-fous dès le début de vos fonctions pour éliminer rapidement les cas invalides.

    Si la logique devient trop conditionnelle, refactorisez-la en utilisant du polymorphisme ou des design patterns adaptés.

  • Gérez les erreurs proprement

    La gestion des erreurs doit être claire et cohérente. Privilégiez les exceptions aux codes d’erreur. Elles rendent le comportement du programme plus lisible et évitent de multiplier les vérifications conditionnelles.

    Les messages d’erreur doivent être informatifs et précis pour faciliter le débogage.

  • Supprimez le code mort

    Un code inutilisé, comme des variables non appelées, des fonctions obsolètes ou des commentaires laissés pour référence, encombre votre projet. Garder ce type de code ne sert à rien et rend la base plus difficile à maintenir.

    Supprimez-le systématiquement. Si besoin, l’historique Git est là pour retrouver une ancienne version.

  • Rendez votre code testable

    Un code propre est un code testable. Pour cela, vos fonctions doivent être petites, indépendantes et sans effets de bord. Cela facilite l’écriture de tests unitaires précis, garantit la robustesse de vos modifications et limite les régressions.

En appliquant ces principes, notamment KISS pour rester simple et YAGNI pour ne pas anticiper inutilement, vous produirez un code qui est à la fois clair, robuste et maintenable. A ces principes, il est possible d'ajouter des principes complémentaires, qu'on appelle les principes SOLID. Nous allons voir ça, juste après.

Les 5 principes complémentaires : SOLID

Pour compléter les 10 principes explicités précédemment, il existe SOLID. C’est un acronyme regroupant cinq principes de conception en programmation orientée objet. Ils sont essentiels pour créer des architectures logicielles maintenables, flexibles et évolutives. Ces principes ont également été popularisés par Robert C. Martin et son aujourd’hui un véritable guide pour les développeurs dans la conception de code robuste et efficace.

Voyons ensemble ces 5 principes :

Single Responsibility Principle (SRP) - Principe de Responsabilité Unique

Une classe doit avoir une seule responsabilité, c’est-à-dire une seule raison de changer.

Open/Closed Principle (OCP) - Principe Ouvert/Fermé

Votre code doit être ouvert à l’extension mais fermé à la modification.

Liskov Substitution Principle (LSP) - Principe de Substitution de Liskov

Une classe dérivée doit pouvoir remplacer sa classe parente sans altérer le comportement du programme.

Interface Segregation Principle (ISP) - Principe de Ségrégation des Interfaces

Une interface ne doit contenir que ce dont une classe a besoin.

Dependency Inversion Principle (DIP) - Principe d'Inversion des Dépendances

Vos classes doivent dépendre d’abstractions (interfaces ou classes abstraites), et non de détails concrets.

L’essentiel à retenir des principes du Clean Code

Finalement ce qu'il faut  retenir, c’est que le Clean Code ne se limite pas à une liste de règles à appliquer mécaniquement. C’est avant tout une approche qui vise à produire un code de qualité. Vous devez toujours vous demander : est-ce que quelqu’un d’autre pourra lire mon code et le comprendre facilement ? Est-ce que moi, dans six mois, je pourrai m’y retrouver sans passer une heure dessus ? Si la réponse est non, alors il y a du travail.

On va garder l’essentiel ici. Il y a quelques principes fondamentaux sur lesquels vous ne devez jamais transiger :

  • Un code lisible est la priorité : noms explicites, fonctions concises et une seule responsabilité par élément.
  • KISS (Keep It Simple, Stupid) et YAGNI (You Aren’t Gonna Need It) doivent guider votre réflexion : gardez le code aussi simple que possible et n’anticipez pas inutilement les besoins futurs.
  • Le DRY (Don’t Repeat Yourself) est fondamental : évitez la duplication de logique pour faciliter la maintenance.
  • Les principes SOLID assurent une architecture modulaire et flexible : chaque classe est centrée sur un rôle précis, ouverte à l’extension, et découplée des détails concrets.
  • Enfin, un code propre est testable, sans code mort, avec une gestion claire des erreurs et une logique conditionnelle simplifiée.

Les 7 étapes pour mettre en place le clean code dans ses projets

Maintenant qu’on a vu les divers principes, voyons comment les appliquer efficacement. Pour cela, il ne suffit pas de connaître les règles, il faut les intégrer dans la pratique quotidienne et dans la culture de l’équipe. Mettre en place le Clean Code demande de la méthode, de l’engagement et un effort collectif.

Voici selon nous, les étapes à suivre pour y parvenir :

  • Étape 1 : Sensibilisez les équipes au clean code

    Avant tout, il est important que tout le monde comprenne pourquoi le Clean Code est essentiel. Organisez des sessions de présentation ou de formations pour expliquer les principes clés et montrez des exemples concrets.

  • Étape 2 : Fixez des standards communs

    Pour assurer la cohérence, définissez des conventions de code adaptées à votre équipe. Cela inclut le naming des variables, la structure des fichiers, la taille des fonctions et les règles d’architecture. Documentez ces standards et assurez-vous que tout le monde les applique.

  • Étape 3 : Intégrez la revue de code dans votre workflow

    Les code reviews sont un outil indispensable pour garantir la qualité du code. Planifiez des revues régulières pour identifier les problèmes, échanger des bonnes pratiques et aider les développeurs à progresser. Une bonne revue de code est collaborative et pédagogique, pas un tribunal.

  • Étape 4 : Adoptez des outils d’analyse statique

    Utilisez des outils comme SonarQube, ESLint ou PHPStan pour automatiser l’analyse de votre code. Ces outils repèrent les erreurs courantes, les duplications et les violations des principes du Clean Code. Ils permettent d’avoir une première validation objective avant même la revue par un pair.

  • Étape 5 : Encouragez le refactoring continu

    Le Clean Code ne concerne pas seulement le nouveau code. Si votre base est déjà en place, il est essentiel d’améliorer progressivement l’existant. Planifiez des sessions régulières de refactoring pour corriger les problèmes techniques accumulés (code legacy, duplication, dette technique). Modifier le code petit à petit, à chaque nouvelle fonctionnalité ou bugfix.

  • Étape 6 : Rendez les tests unitaires obligatoires

    Un code propre est un code testé. Intégrez des tests unitaires dans votre processus de développement et dans vos pipelines CI/CD. Encouragez l’écriture de tests systématiques pour chaque nouvelle fonctionnalité ou modification. Cela garantit la robustesse du code et facilite les évolutions futures.

  • Étape 7 : Faites-en une culture d’équipe

    Le Clean Code ne doit pas être une contrainte, mais une habitude collective. Chaque développeur doit se sentir responsable de la qualité du code qu’il produit. Favorisez un état d’esprit, une philosophie où la qualité prime et où chacun s’entraide pour écrire le meilleur code possible. C’est en travaillant ensemble que ces pratiques deviendront un réflexe naturel.

Envie d'en savoir plus ?

Découvrez également nos bonnes pratiques pour limiter la dette technique de vos applications !

Télécharger le guide
Comment réduire la dette technique de son application ?

Les meilleures pratiques et outils du clean code en Javascript

Avec le langage de programmation JavaScript (Node.js, Vue.js, Next.js, React.js), le nommage des variables et des fonctions est essentiel pour maintenir un code propre. Utiliser des noms descriptifs et suivre une convention de nommage cohérente, comme camelCase, améliore la lisibilité. Modulariser le code en utilisant les modules ES6 est une autre bonne pratique, car cela favorise la séparation des préoccupations et rend le code plus gérable et testable.

Pour vous y aider, il est possible d'utiliser divers outils :

  • ESLint : Analyse statique pour repérer erreurs et mauvaises pratiques.
  • Prettier : Formateur pour une mise en forme cohérente.
  • Jest : Frameworks pour écrire des tests unitaires.
  • SonarQube : Analyse de qualité de code.
  • TypeScript : Typage statique pour améliorer la lisibilité et réduire les bugs.

Exemple concret d’application du clean code

Pour illustrer comment les principes du clean code peuvent être appliqués dans la pratique, prenons un exemple concret dans un composant React qui affiche la liste des utilisateurs avec un bouton pour les supprimer. À première vue, il fonctionne, mais il enfreint plusieurs principes du clean code.

Exemple avant refactoring (bad code)

Exemple d'un code n'intégrant pas les principes du clean code

Ce code est complexe : Fonction trop longue, noms peu explicites, pas de réutilisabilité, mélange logique et affichage.


Exemple après refactoring (good code)

Maintenant, voyons comment refactoriser ce code en appliquant les principes du clean code :

Exemple de code refactorisé intégrant les principes du clean code

Dans cette version refactorisée, plusieurs principes du clean code ont été appliqués :

Découpage clair :

  • Le hook useUsers gère la logique métier (récupération et suppression).
  • Le composant UserList se concentre uniquement sur l’affichage.

Code lisible et simple :

  • Le composant est court, facile à comprendre et respecte le principe KISS.

Réutilisabilité :

  • Le hook useUsers peut être utilisé dans d’autres composants si nécessaire.

Conclusion

Le Clean Code, c’est la clé pour écrire un code lisible, maintenable et de qualité. Retenez l’essentiel : appliquez la simplicité avec KISS, évitez la duplication avec DRY, respectez les conventions de code et améliorez le code chaque fois que vous le touchez (règle du Boy Scout).

Les principes SOLID, le refactoring régulier et des outils comme ESLint ou Prettier vous aideront à maintenir cette qualité sur le long terme. Ajoutez à cela des tests unitaires pour sécuriser vos modifications.

En intégrant ces pratiques dans votre routine, vous simplifierez votre travail, faciliterez la collaboration avec votre équipe et créerez des logiciels robustes et évolutifs.

Un doute sur la lisibilité de votre code ?

Contactez l'un de nos experts pour auditer votre code !

Demander un rendez-vous
Prenez un RDV avec un expert Eleven Labs

Découvrez d’autres articles autour du développement web et mobile