URL: https://linuxfr.org/users/swilmet/journaux/petitew-longue-critique-du-livre-code-complete Title: Petite^W Longue critique du livre Code Complete Authors: Sébastien Wilmet Date: 2011年08月04日T23:22:21+02:00 Tags: livre, programmation, critique, livre_technique et donald_knuth Score: 25 J'aime bien suivre l'actualité générale autour du Libre (comprendre : lire DLFP), suivre quelques blogs, etc. Mais j'aime bien aussi lire des livres traitant d'informatique. Et le dernier en date, c'est justement [Code Complete, de Steve McConnell](http://cc2e.com/) (2e édition). [/!\ § d'accroche] En bref : si vous aimez la programmation, il y a des chances que vous aimerez encore plus ce « métier » situé entre l'art et l'ingénierie après avoir lu ce livre. En tout cas c'est mon sentiment. # Un petit problème... # Alors, pour ceux qui ont déjà cliqué sur le premier lien, oui, l'éditeur est Microsoft Press. Ne pas acheter ce livre juste à cause de ça est idiot ÀMHA. Comme je suis un libriste comme tout le monde ici, mon avis sur le sujet vous semblera peut-être intéressant : - Déjà, les exemples de code, qui sont assez nombreux, sont soit en C++ (bien), Java (moins bien) ou Visual Basic (argh !). Mais dans ce genre de livre, le langage n'a pas trop d'importance. Et le Visual Basic n'a pas une syntaxe trop exotique, pas comme le Smalltalk par exemple qui est parfois utilisé dans le livre [Design Patterns](http://en.wikipedia.org/wiki/Design_Patterns). - Le lien avec Microsoft ou Windows se limite juste à quelques références ou anecdotes. De ce point de vue là, c'est très varié. - Le monde OpenSource, de UNIX et de GNU/Linux n'est pas oublié, mais on peut regretter une absence totale du Libre (eh non, [OpenSource ≠ Libre](http://www.framablog.org/index.php/post/2009/10/02/logiciel-libre-open-source)). # OK. Mais de quoi traite ce livre au juste ? # Construire un programme qui fonctionne, ce n'est pas difficile. En construire un dont le code est simple à comprendre, qui est facilement maintenable, et où on n'a pas perdu du temps à travailler sur des choses inutiles ou peu significatives, c'est une autre paire de manches. Code Complete explique donc plein de bonnes pratiques pour arriver à cet objectif. Dans un projet de programmation, écrire le code source est inévitable. Donc autant le faire le mieux possible. Mais en-dehors de l'écriture du code, il peut y avoir beaucoup d'autres choses (surtout dans les entreprises, moins pour un projet personnel) : - définir le problème à résoudre ; - définir le cahier des charges, les exigences ; - réfléchir à l'architecture du logiciel ; - {écrire le code} ; - tester et déboguer ; - intégration des différents composants ; - refactoring (améliorer du code existant) ; - améliorer les performances, mais pas n'importe comment. Tout ceci ne se fait évidemment pas séquentiellement, mais de manière itérative. Ainsi, si on fait une erreur dans une des premières étapes, on s'en rend plus vite compte, et l'impact est moins important. Code Complete parle de tous ces sujets, mais les trois premiers points de manière résumée/introductive. Et pour les autres sujets autres que {écrire le code} (qui est la partie la plus développée du livre), il y a pas mal d'explications, mais en fin de chapitres il y a à chaque fois des références vers d'autres bouquins plus complets. # Quelques exemples de bonnes pratiques # Vous vous demandez surement comment on peut écrire un ouvrage de 900 pages, alors que le sujet principal est l'écriture de code. Quels genres de conseils y sont donnés ? Pour donner un exemple très précis, prenons l'écriture du nom d'une fonction. Le nom d'une fonction, c'est très important, pour savoir ce qu'elle fait exactement, et pour la retrouver et la réutiliser facilement quand on en a besoin. Si avant de commencer à écrire la fonction, on a du mal à lui donner un nom, c'est qu'il y a un problème : on n'a pas bien réfléchi à l'avance ce que la fonction est censée faire exactement, et dans ce cas-là, soit on lui donner un nom bateau genre « handle_stuff() », et la fonction fait plein de diverses choses. Soit on change d'avis, et au lieu d'écrire une fonction fourre-tout, on la décompose en plusieurs fonctions qui ne font qu'une chose, mais qui le font bienTM. Tient, ça ressemble vachement à la philosophie UNIX ! Et là, les programmeurs chevronnés se disent : « pff, c'est tout à fait logique, je n'ai pas besoin de ce genre de conseils ». Sur ce point-là, je n'ai pas un avis très tranché. Il y a quelques parties du livre (mais pour ma part ça ne représentait pas beaucoup) qui s'adressent clairement aux débutants. D'ailleurs dans ce cas, il y a un avertissement au début du chapitre, pour dire que certains peuvent sauter une ou plusieurs sections. En tout cas, sur la quatrième de couverture, il est clairement marqué que c'est adressé tant aux débutants qu'aux programmeurs plus expérimentés. En programmation, il y a beaucoup de choses qu'on fait par habitude. Si on prend des bonnes habitudes dès le début, tout va bien. Mais le problème c'est qu'on est pas toujours conscient qu'on a pris de mauvaises habitudes. Je vais prendre un exemple qui m'a assez choqué dans le livre, mais qui s'avère au final bénéfique. Pratiquement tous les programmeurs, pour écrire des boucles, utilisent les noms de variables i, j, voir k (mais trop d'imbrications rend le code plus difficile à suivre, mais là n'est pas le sujet). Il est conseillé d'utiliser plutôt des noms plus long qui décrivent bien ce que l'index représente. Ainsi, quand on veut modifier la valeur d'un tableau imbriqué par exemple, au lieu de lire :> `score[i][j] = ...;` on lit :> `score[ teamIndex ][ eventIndex ] = ...;` En ayant des noms plus explicites, en rapport avec le domaine d'application, il y a moins de risque de confondre les deux variables, et on comprend mieux ce que le code fait. Et pourtant, l'utilisation des i, j, etc. est très très courant. Pourquoi ? Si c'est pour _écrire_ le code plus vite, ce n'est pas une bonne raison. On lit beaucoup plus de code qu'on en écrit. En règle générale, il faut écrire du code non pas pour la machine, mais pour soi-même et les autres personnes qui vont le lire. Il y a comme ça certains conseils généraux qui sont souvent répétés. Certains préfèrent que certaines informations soient répétées pour mieux les retenir, d'autres trouvent ça inutile. Pour ces derniers, il y a peut-être [d'autres livres](http://en.wikipedia.org/wiki/Pragmatic_Programmer) sur [le même sujet](http://netlib.bell-labs.com/cm/cs/pearls/) qui leurs conviendraient mieux. # Autres points généraux sur lequel l'auteur insiste # - Un des buts premiers de la programmation est de gérer la complexité, en faisant abstraction de certaines choses, à tous les niveaux. L'exemple typique est la programmation orientée objet : pour utiliser une classe, il ne faut pas (normalement) savoir comment elle fonctionne en interne. - Programmer en termes du problème au lieu des détails techniques. Par exemple on s'en fiche de savoir quelle structure de données est utilisée pour stocker certaines informations. Donc on préfèrera des noms de fonctions tels que get_last_document() plutôt que get_top_stack(). - Faire attention aux signes qui montrent que notre code est mal écrit : par exemple quelqu'un qui nous dit que notre code est difficile à comprendre. Ou bien des warnings lors de la compilation, etc. - Ne pas se focaliser sur une seule et unique méthode. Aucune méthode n'est parfaite pour tous les types de projets. Trouver les bonnes techniques se fait par une heuristique, il n'y a pas de procédé clairement défini. C'est comme un ouvrier avec une boite à outils. Il n'y a pas un outil qui convient pour tout. # Un bon point de départ # Le texte est rempli de références vers d'autres ouvrages, donnant souvent envie d'en apprendre plus. Le dernier chapitre est d'ailleurs consacré rien qu'à ça. Peut-être qu'en lisant ce journal, vous avez pensé à [The Art of Computer Programming](http://en.wikipedia.org/wiki/The_Art_of_Computer_Programming) de Donald Knuth. Cette série de livres détaille en profondeur l'algorithmique et les structures de données. Code Complete aborde évidemment aussi ce sujet, mais il en aborde tellement d'autres que ce n'est pas comparable. # Que dire de plus ? # Encore beaucoup de choses, mais je vais m'arrêter là pcq c'est déjà suffisamment long comme ça. Pour ceux qui ont lu jusqu'ici, merci :) Ah non, j'ai menti, encore une chose. Je pense qu'il existe une traduction en français, mais comme toute traduction d'un livre informatique écrit à la base en anglais, il est plutôt conseillé de lire l'original. J'ai déjà vu des livres en français où le code source était mal formaté, des mots comme CPU sont traduits en UC (Unité Centrale), etc. Bref, à déconseiller.

AltStyle によって変換されたページ (->オリジナル) /