UN BON CODE ...

Dans l'ordre, un bon code

1. passe ses tests avec succès;
2. ne peut être mal utilisé;
3. ne contient pas de redondance;
4. exprime clairement l'intention;
5. est aussi court que possible.

Paraphrase ...
A peu de choses près, les points 1, 3, 4 et 5 sont une citation de Kent Beck, créateur de l'eXtreme-Programming. Praticien de la programmation par contrat, j'y ai rajouté le point 2. (Qu'est-ce que je ne ferai pas pour citer les travaux de Kent Beck et Bertrand Meyer dans le même billet :o)

... néanmoins utile
J'ai la chance de relire beaucoup de code, de binommer avec de nombreux développeurs et d'enseigner. Dans le cadre de ces activités, cette citation en cinq points m'est très utile. Je m'en sers beaucoup et je la cite souvent. Je dois sûrement passer pour un extrémiste dogmatique et têtu ... (Après tout dans un équipe, il est bon d'atteindre un certain ratio développeur extrémiste / développeur laxiste)
N'empêche qu'il y a beaucoup de sagesse empirique dans cette citation. Entre autre, l'ordre des critères est très important.

1. Tu testeras
Les tests occupent le haut du podium. Un code qui n'est pas testé n'a pas de valeur. C'est du code sans garantie. Toute ligne d'instruction doit être couverte par un test. Cela se vérifie très bien avec les outils d'analyse de la couverture structurelle.

2. Tu détromperas
Un code qui ne peut être mal utilisé est un code détrompé. Il contribue à la gestion préventive des défauts dans l'application. La programmation par contrat est une excellente pratique pour détromper le code. Quitte à parler de programmation par contrat, il serait plus exacte de dire: "Un bon code garantie sa postcondition si sa précondition est garantie par son appelant". Pour en savoir plus sur cette pratique rare mais vraiment efficace, vous pouvez lire un précédant billet sur ce sujet.

3. Tu ne te répèteras pas
La duplication est source de défauts multiples et de reprises multiples. Elle nuit à la clarté des intentions. Admettons que j'"hérite" d'un code non testé. Sans hésitation, je préfère consacrer du temps à le tester qu'à en éliminer les redondances. (En fait, j'éliminerai les redondances dès que les tests passeront :o)

4. Tu seras clair et explicite
Le code est bien plus souvent lu qu'écrit - y compris par son auteur! D'ailleurs, l'écrivain est avant tout son propre lecteur. Autant faciliter la vie de tous ces relecteurs. Comme pour le point précédant, je préfère tester que renommer et découper. (Pareil, je renommerai et découperai dès que les tests passeront :o)

5. Tu seras bref
La brièveté du code arrive en dernier car elle peut entrer en conflit avec les points 1, 3 et 4. Dans un tel cas de figure, la brièveté n'est pas prioritaire.
Pour rendre un code testable, il faut souvent créer des interfaces pour injecter des dépendances à la construction des objets. Cela augmente la taille du code. Le test amène également à découper en petites classes et il y a un talon déclaratif à payer pour cette modularité.
Un code sans duplication peut amener à créer une opération pour 2 lignes dupliquées. Au total, en comptant le surcroit de déclaration, cette pratique peut augmenter le nombre de lignes. D'ailleurs, avez vous remarqué que les exemples de code remanié sont TOUJOURS plus longs que leur code d'origine? (voir Clean Code)
Pour rendre un code plus explicite, nous sommes amené à homogénéiser le niveau d'abstraction dans le code des opérations. Pour cela, nous encapsulons le code de niveau d'abstraction inférieur dans une opération. Là encore, nous payons une taxe pour la déclaration des opérations.

Et le code des tests?
Ce codex en 5 règles s'applique au code, mais aussi aux tests, car les tests sont du code. On peut penser qu'il ne faut pas tester les tests sinon on n'en finit jamais. Pourtant, la pratique du Test Driven Developpment issue de l'eXtreme-Programming intègre par construction le test du test!
En effet, lorsque nous commençons par écrire un test qui échoue, puis nous modifions le code jusqu'à ce que le test passe avec succès, nous vérifions la justesse du test. Ce tte démarche en 2 étapes est le test du test.

Un de plus (violation du critère 3!)
Désolé, ceci était le 1379ème billet visant à définir un bon code. Plusieurs livres y consacrent leurs pages. C'est un peu comme les chaînes de chance/malchance. Lorsqu'on lit un de ces billets, on se doit d'en écrire un à son tour ...