Avant de poursuivre, je vous invite à consulter mon article dédié au TDD.
Il s’agit également d’une prise de notes inspirée du livre Software Craft. Voici mon résumé synthétisé :
N’importe qui peut écrire du code que l’ordinateur comprend; seuls les bons développeurs écrivent du code que les humains comprennent.
Les questions à se poser
- Le code n’est-il pas trop complèxe pour ce quíl fait ?
- N’est-il pas possible de le simplifier ?
- Les abstractions et autres généralisations introduites le sont-elle à bon escient ?
- Est-ce qu’on anticipe pas trop sur un possible futur ?
- Est-ce qu’on comprend à la première lecture ce que le code cherche à faire ?
- Le code ne tend-il pas à se répéter ? Est-il pertinent d’en réduire la duplication ?
- le design mis en place autorise-t-il suffisamment de liberté pour la suite ?
Les règles du clean-code
- Rester simple et aller à l’essentiel.
- Révéler l’intention du code
- Découper les fonctions
- Respecter l’art du naming
- Respecter l’art du Storytelling
- Lorsque l’on modifie du code existant, il doit être mieux écrit que précédemment.
- Respecter les règles de structure de code (Formatage, Respect des standards, Indentation, )
- Respecter les niveaux d’abstractions (une fonction enfant doit être en dessous de celle qui l’appelle)
- Ne pas contourner la règle d’une seule sortie de paramètre par fonction, Si la valeur est complèxe on l’encapsule dans un type dédié.
- Restraindre le nombre de variable, et le définir au bon endroit
- Commenter du code si il y a une subtilité, pour aider à comprendre le code; Marquer des problèmes à résoudre (ex : Todo); Apposer des mentions légales.
- Appliquer ces règles au test.
- Passer les tests
Naming
- Privilégier les nom communs pour les classes et les verbes pour les méthodes.
Anti-Pattern
- Acronymes et Abréviations, sauf si le terme fait parti du champ lexical du projet.
- Termes fourre-tout (ex : Data, Info, Manager, Service) cela rajouter du bruit inutile.
- Utilisation du Paramètre* (ex : GetArrrayOfProduct → GetProducts)
- Les noms trop court (ex : i → index)
- Paramètres* ou d’argument identique au type (ex : string str)
- Nom trop long, si il est trop long c’est qu’il est possible de découper
Acronymes à garder à l’esprit :
- KISS → Keep It Simple And Stupid
- YAGNI → You Ain’t Gonna Need It
- TDD → Test Driven Development
- DRY → Don’t Repeat Yourself
*Paramètre → type de sortie (return) d’une fonction
Laisser un commentaire