Accéder à l'en-tête Accéder au contenu principal Accéder au pied de page
Retour aux actualités
Bonnes pratiques de dév
14/11/2013 Cyrille Martraire

What Is Clean Code?

(Résumé du début du livre Clean Code de Robert C. Martin)

Rappelons-nous que le code est vraiment la langue dans laquelle nous exprimons en fin de compte les exigences.

N’importe quel logiciel est constitué de code, nous pouvons créer des langages qui sont au plus près des besoins business, nous pouvons créer des outils qui nous aident à analyser et traduire ces exigences, mais il y aura toujours du code, et plus ce code est clean plus le logiciel est maintenable et évolutif.

Mais comment doit être un code clean? C’est le but de cet article.

Bad Code

Vous avez déjà été considérablement gêné par le mauvais code, vous avez sûrement senti cet obstacle plusieurs fois, mais pourquoi l’avez-vous écrit ? Si vous êtes développeurs, vous avez forcément écrit un jour du mauvais code, c’est inévitable, et les raisons sont multiples, et certainement bien claires dans vos têtes:

  • Essayer d’aller vite.
  • Pas de temps à perdre sur cette feature.
  • Vous n’avez pas eu le temps de faire un bon travail.
  • Votre patron serait en colère contre vous si vous preniez le temps de nettoyer votre code.
  • Peut-être que vous étiez fatigué de travailler sur ce programme et vous vouliez que ce soit fini.

Peu importent les raisons, le point commun à cette session de mauvais code est toujours une promesse malheureusement vite dite et vite oubliée, “je nettoierai plus tard”.

Une fois que notre code marche, on se dit : un mauvais code qui marche, c’est mieux que rien, puis on passe à autre chose avec l’idée de nettoyer plus tard, sauf que Plus tard est égal à jamais.

Seulement voilà, plus les features s’accumulent, plus le mauvais code est présent, et moins votre logiciel est maintenable, ce qui se traduit par une productivité de l’équipe qui ne cesse de diminuer, et qui tend finalement vers zéro. Ce qui nous mène à la nécessité de réécrire le code, proprement cette fois ci, afin d’y voir plus clair

Graph Clean Code

Clean code ?

Vous êtes  bien conscient qu’un mauvais code est un obstacle important, et la seule façon d’aller vite est de garder le code propre.

La question qui se pose est « Comment pouvez-vous écrire du code propre », il n’est pas possible d’essayer d’écrire du code propre si vous ne savez pas ce que cela signifie!

  • Un code propre est avant tout un code qui doit être agréable à lire.
  • Un mauvais code permet au désordre de grandir! Plus on a des bouts de code mauvais, plus la qualité de notre logiciel tend vers la décadence.
  • Un code propre doit prêter attention aux détails et doit être est focalisé, chaque fonction, chaque classe, chaque objet expose une attitude simple qui reste entièrement indépendante, et non polluée par les détails non nécessaires.
  • Un code propre doit clairement exposer le problème à résoudre et ne doit contenir que ce qui est nécessaire.
  • Il y a  une différence entre le code qui est facile à lire et le code qui est facile à changer, un code propre doit être facile à améliorer par d’autres personnes.
  • Un code non testé n’est pas un code propre, peu importe s’il est lisible et accessible.
  • Un code propre est un code qui a été pris en charge par quelqu’un qui a pris le temps de rester simple et ordonné.
  • Ne contient pas de duplication.
  • Un code propre est aussi un code qui réduit au maximum le nombre d’entités telles que les classes, méthodes, etc.
  • Évident, simple et convaincant: quand on lit un code propre, on ne doit dépenser trop d’effort pour le comprendre,

Savoir si le code est propre ou mauvais n’est pas suffisant, comment peut-on écrire un code propre ?

Plusieurs techniques et bonnes pratiques faciles à adopter existent pour aider à écrire un code propre : nommage explicite de vos fonctions et variables – se passer de commentaires le plus possible, fractionnement de votre code en de multiples petites fonctions et bien d’autres … ce sera le sujet de mes prochains articles.

En attendant n’oubliez jamais, ce sont les programmeurs qui font que le langage paraît simple!