Livres Compilateurs

En plus d'être bien écrit, ce qui n'est pas si courant dans le domaine informatique, ce livre contient une quantité phénoménale d'information sur tout ce qui touche son objet. Le tout est fort bien organisé pour favoriser la compréhension, pas seulement pour ingurgiter des détails arides à la pelletée.

Étudiant de longue date d'Unicode et de l'internationalisation, je ne peux qu'être d'accord avec Mark Davis qui dit dans sa préface qu'il n'existe pas d'autre ressource, en français ou en anglais, couvrant tant de terrain de façon si claire et accessible. Recommandé pour quiconque a une petite curiosité de ce qui se passe sous le capot de son ordinateur, et a fortiori pour qui a besoin de savoir pour son boulot !

Voilà un livre indispensable si on s'intéresse à la construction de compilateurs ou d'interpréteurs. Il peut être considéré comme dépassé ou incomplet par certains. Les dernières techniques d'analyse ne sont peut-être pas étudiée. Mais il s'agit d'une légende. C'est le "dragon book" !
Il faut l'avoir lu. Peut-être pas complètement car il a 1000 pages et c'est très gros.
Pour la programmation en C il y a le K&R. Pour les compilateurs il y a le "dragon book".

De plus la version française est à environ 60 EUR alors que la version US est à 100 EUR. Il faut en profiter sans hésitation.

Un livre écrit par un développeur pour les développeurs.
Petit par sa taille, il va à l'essentiel. Il donne des conseils judicieux et va bien au delà d'autres volumes écrits avant la parution du logiciel pour vendre.
Il n'apprend pas VB .Net, mais comment l'utiliser dans des applications Smart Devices. Il est très éclectique : on y apprend à utilser SQL Server, à envoyer un SMS (par Outlook), à suivre un véhicule par GPS, à installer une application.
En un mot, un MUST.
J'ai acheté des dizaines de livres sur Amazon, mais c'est la première fois que je fais l'effort d'un commenter un.

Très bon livre pour aborder et perfectionner ses connaissances sur le développement des compilateurs. J'ai le "Dragon book" qui lui est très théorique et beaucoup plus aride. Ce livre aborde beaucoup plus rapidement les cas pratiques sans oublier la théorie mathématique. Je le conseillerai à quelqu'un qui a besoin d'écrire un compilateur et/ou un interpréteur rapidement et qui a fini ses études depuis très longtemps et qui n'a plus d'examens à passer.
Il reste un très bon complément au "dragon book"

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.