La callisthénie des objets est une pratique de programmation qui implique une totale maitrise de son code.
La callisthénie est une pratique sportive qui consiste à utiliser le poids de corps et la gravité pour effectuer des exercices de musculation impliquant une totale maitrise de son corps.
Quel rapport avec le clean code me direz-vous ? En 2008, Jeff Bay (programmeur chez ThoughtWorks) propose un ensemble de 9 règles de codage dans le chapitre du livre The Thoughtworks Anthology intitulé "Object Calisthenics". Le but de cet exercice : produire un code orienté objet d'excellente qualité.
Ces règles sont axées sur la maintenabilité, la lisibilité, la testabilité et la compréhensibilité de votre code. Voici la liste de ces règles :
- Un seul niveau d'indentation par méthode
- Ne pas utiliser le mot clé ELSE
- Envelopper tous les types primitifs et les string
- Collections "de première classe"
- Un point par ligne
- Ne pas abréger
- Maintenir toutes les classes petites
- Aucune classe avec plus de deux variables d'instance
- Pas de Getters / Setters / Properties
1. Un seul niveau d'indentation par méthode
Qui n'a jamais vu ce genre de code dans ses projets ? Imaginez maintenant que le style d'indentation ne soit pas de type K&R mais plutôt GNU, Allman ou bien encore Whitesmiths... Il s'agit bien sûr d'un cas extrême. Mais une méthode qui possède déjà 3 niveaux d'indentation (if, for, ...) devient déjà compliqué à lire et à comprendre.
Voici déjà 3 techniques qui pourront vous aider à appliquer cette première règle :
2. Ne pas utiliser le mot clé ELSE
3. Envelopper tous les types primitifs et les string
4. Collections "de première classe"
5. Un point par ligne
6. Ne pas abréger
Pourquoi abréger ? La réponse qui m'est généralement faite : gagner du temps. OK, prenons l'exemple suivant, exemple inspiré fortement d'un code réel :
var factu = compta.GenFactu(42);
Hum.. "Compta"... Comptabilité ? Comptable ? Nous sommes ici obligé de regarder le type de l'objet pour savoir. "GenFactu"... ? Générer facturation ? Générer facture ? A priori ici générer facture... Facture ? Facturation ? Facture certainement. Nous avons effectivement gagné 11 caractères. Whaou ! Nous avons gagné au moins 1 seconde à l'écriture. Combien de temps perdu à effectuer le mapping mentale pour comprendre cette ligne ? 1 seconde ? Maintenant combien de fois allons nous relire ce code (revue de code, tests, debugging, ...) ? Donnons un minimum de 3 fois. Cela veut dire que, de base, pour 1 seconde de gagner, 3 de perdues. Il s'agit ici d'un code simple isolé. Maintenant imaginons la même chose à l'échelle d'un projet de 500.000 lignes...
var facture = comptable.GenererFacture(42);
Est-ce que le gain en vaut la chandelle ? Pas sûr. Robert C. Martin, autorité dans le domaine du clean code, consacre un chapitre entier de son livre Clean Code à l'importance du nommage (Meaningful Names).
7. Maintenir toutes les classes petites
8. Aucune classe avec plus de deux variables d'instance
9. Pas de Getters / Setters / Properties
