Ce que Clean Code m’a appris sur le code propre

Quand j’ai lu Clean Code de Robert C. Martin – qu’on appelle souvent Uncle Bob –, j’étais déjà développeur depuis plusieurs années. Mais ce livre m’a vraiment poussé à remettre en question certaines habitudes que je croyais “bonnes”. Voici quelques leçons qui m’ont marqué, et que j’essaie d’appliquer au quotidien.
1. Un bon code se lit comme un bon texte
Avant Clean Code, je pensais que mon code devait surtout fonctionner. Après l’avoir lu, j’ai compris qu’il devait surtout se lire facilement. Uncle Bob insiste sur le fait qu’un bon code, c’est comme une bonne histoire : claire, fluide, sans ambiguïté. Il faut penser au prochain développeur qui va le lire (même si ce développeur, c’est toi dans 6 mois !).
2. Le nommage, c’est plus important que je ne le croyais
J’ai longtemps sous-estimé l’importance de choisir de bons noms pour les variables, fonctions, classes. Pourtant, un bon nom peut parfois éviter des commentaires ou même des bugs. Uncle Bob pousse à donner des noms précis, parlants, et à éviter les abréviations floues. Depuis, je prends plus de temps pour nommer les choses, et ça fait une vraie différence.
3. Les fonctions doivent être courtes et faire une seule chose
Une des règles les plus connues du livre : une fonction doit faire une seule chose, et le faire bien. Ça paraît évident, mais dans la pratique, ce n’est pas si facile. J’ai appris à découper mon code, à éviter les blocs trop longs, et à chercher la simplicité. Parfois, supprimer du code est aussi un progrès.
4. Les commentaires ne remplacent pas un bon code
J’aimais bien documenter mon code avec plein de commentaires. Mais Clean Code m’a appris que le meilleur commentaire, c’est souvent celui qu’on n’a pas besoin d’écrire, car le code est déjà clair. Bien sûr, certains commentaires sont utiles (quand on explique une décision ou un contexte), mais ils ne doivent pas cacher un code mal écrit.
5. La propreté du code, c’est une discipline
Enfin, j’ai retenu que le code propre ne vient pas par hasard. C’est un effort constant, une façon de penser. Ça demande de la rigueur, de l’humilité, et parfois du courage pour refactorer ce qui “fonctionne déjà”. Mais au final, c’est ce qui fait la différence entre un bon projet et un projet qui devient vite ingérable.
Conclusion : Clean Code ne donne pas de recettes magiques, mais il aide à adopter un état d’esprit. Depuis ma lecture, je vois le code autrement. J’essaie de le rendre lisible, maintenable, agréable à faire évoluer. Et même si je n’y arrive pas toujours, je sais maintenant dans quelle direction aller.
Et toi, quelles leçons t’ont marqué dans Clean Code ? 😊