Tout sur le code : Pour concevoir du logiciel de qualité [Broché]

Le meilleur investissement que puisse faire un développeur consiste sans doute à acheter ce livre et à en faire son livre de chevet. Beaucoup en ont réellement besoin, à commencer par ceux qui disent « Non, pas moi. ».

Je considère d'ailleurs qu'un développeur qui croit n'avoir pas besoin de lire ce livre ou un livre similaire (Code Craft, The Practice of Writing Excellent Code de Peter Goodliffe, par exemple) est un développeur *dangereux* pour son employeur. Son code est probablement difficilement maintenable, y compris par lui-même.

Évidemment, le seul fait de lire un tel livre ne fait pas instantanément d'un débutant un expert confirmé. Mais ce livre fait naître les bons réflexes, c'est-à-dire ceux qui mènent à l'expert confirmé, justement. Après cette lecture, vous ne lirez plus votre code et celui des autres de la même façon. Vous ne vous poserez plus les mêmes questions -- vous vous poserez les *bonnes* questions. Et nous aurons enfin du code maintenable !

Code Complete est un livre exceptionnel en ce qu'il s'intéresse à *tous* les aspects du développement logiciel, l'accent étant mis sur la réalisation (ou programmation) dont rien n'est laissé au hasard :

- Quelles sont les meilleures pratiques pour nommer une variable, une propriété, une constante, une fonction, un fichier, pour tester une méthode, pour restreindre la visibilité d'un symbole ?

- Quelle est la longueur idéale d'une fonction, d'un fichier et pourquoi ?

- Comment effectuer une revue de code efficace ?

- Comment exprimer simplement un test qui fait intervenir quatre OU et trois ET ?

- Comment mettre en oeuvre une table de décision, comment trouver un bug, comment programmer défensivement ?

- Faut-il vraiment éviter les GOTO ? Une fonction doit-elle vraiment posséder un seul return ?

- Quels commentaires pouvons-nous supprimer sans hésiter ? Quelles sont les informations qui doivent figurer dans le cartouche d'une fonction, d'un fichier ? Est-ce vraiment utile ?

- À quel moment doit-on commencer à se soucier des performances ? Comment ordonner les cas d'une instruction Case ? Quand une série de if-else if est-elle préférable à un case ? Et comment doit-on gérer les erreurs ?

Rien dans ce livre n'est gratuit : quand l'auteur propose une avenue, il la justifie systématiquement. Vous pouvez ne pas être d'accord avec lui sur tout, bien sûr, mais il a raison la plupart du temps puisqu'il s'appuie sur son expérience, sur celle des autres et sur de nombreuses études (ou hard data - par exemple, la section concernant les boucle while mentionne les résultats assez étonnants d'une études montrant qu'un programmeur comprend beaucoup plus facilement une boucle dont la condition de sortie est exprimée dans le corps de la boucle plutôt que dans le point d'entrée ou de sortie...).

Ce livre propose assez souvent tout l'inverse des normes de programmation qu'on vous imposera un peu partout (au point d'ailleurs où l'on finit par se demander si ceux qui les rédigent ont déjà fait de la maintenance). Ces normes imposent trop souvent un style de programmation « par principes » (si vous rencontrez telle situation, faites ceci), ce qui est tout le contraire de la programmation « par réflexion » que suggère ce livre. Par exemple, les règles suivantes, que j'ai souvent rencontrées, passent à coté de l'essentiel et sont malheureusement le plus souvent imposées - ce qui génère du code coûteux à maintenir :

- Il faut limiter la longueur d'une ligne à 80 caractères. (Même lorsque la lisibilité et la compréhension du code en pâtit ?)

- Ne pas utiliser une variable nommée i dans les boucles. (Ah bon, ma variable i ne respecte pas les normes mais sa variable nommée int_mon_compteur_de_la_boucle_courante, tout en cachant l'essentiel du traitement, les respecte ?)

- Toute fonction doit tenir à l'écran. (Quitte à scinder un traitement unitaire en quatre fonctions qu'on ne sait plus comment nommer ?)

- Ne pas utiliser de variable globale. (Wow, j'ai une variable globale dans un fichier comptant 100 fonctions et 2500 lignes. Mon voisin n'a aucune variable globale mais passe systématiquement une structure contenant 2500 champs à toutes ses fonctions et c'est moi qui ai tort ?)

Bon, vous voyez le topo. Après la lecture de ce bouquin, vous serez :

- Meilleur développeur.
- Vous produirez du code moins coûteux à maintenir.
- Vous saurez dire non aux normes contreproductives.
- Et surtout, vous serez content chaque matin d'aller au boulot, histoire de lire les sources et de vous dire : ça, franchement, je l'aurais codé de cette façon et voici pourquoi.

J'ai commencé la lecture du livre en anglais, et j'ai fait acheter l'ouvrage en français pour mes collègues qui ne pourraient pas le lire en anglais.
Le livre est absolument remarquable, et devrait être une lecture obligatoire pour tout développeur, même confirmé. Il passe en revue tout ce qu'un développeur devrait savoir, depuis les détails de programmation jusqu'aux aspects du contrôle de la qualité du logiciel. Il se lit tout seul, il fourmille d'exemples de mauvais code et de bon code.
Mais le traducteur ne lui rend pas justice. Traduire "informal code reviews" par "Révision informelle du code" est erroné : on parle de "revues informelles de code" et pas de "révisions" ! On relèvera aussi plein de coquilles (un tilde signifiant "à peu près" transformé en symbole de l'angström, par exemple, un titre "Plus çà change, plus çà reste pareil" (sic)).
Bref, pour tous ceux qui lisent bien l'anglais, jetez-vous sur la version anglaise, nommée "Code complete" (et pas "code review" comme l'indique un autre commentateur) ; allez également voir le blog de Steve McConnell. Pour les autres, achetez cette version, en sachant que le vocabulaire est parfois incorrect et que vous vous énerverez régulièrement devant les coquilles.

Sans conteste, un livre références.
Tout ce qu'il faut faire et qu'il ne faut pas faire pour avoir un bon code.
Je n'en ai pas encore lu de meilleur.
On sent de suite que l'auteur n'est pas le premier venu en programmation informatique.
De l'argent certainement pas utilisé inutilement