Mais c'est une mauvaise excuse. Tu ne dois pas avoir à "indexer" ton code d'une autre manière qu'avec les fonctions qu'il définit.
Mais tu n'as pas besoin de le faire non plus!Tu peux me montrer tout le beau code que tu veux,
je pourrais te répondre que c'est seulement d'après toi qu'il est beau et que son contenu bien choisi.
Je préfèrerai éviter de le lire en entier aux moments critiques, tout simplement parce que le temps ne me sera pas donné pour le faire.
Si tu as un bug qui n'a rien à voir avec une fonction faitMachinBrol, tu n'as pas besoin d'aller voir la fonction faitMachinBrol quand elle est appelée, car tu sais que l'origine n'en est pas là, point.
Et c'est là que je vais te sortir que le bon ouvrier va utiliser les bons outils.Si un bug se balade dans 30 000 lignes de code, on est très mal si on doit compiler de tête 30 000 lignes de code et les interpréter, si l'on en est pas l'auteur.
Les bons outils, c'est:
- le débuggeur pour connaitre l'origine et la destination (AKA l'endroit où ca plante) du bug et
- une liste de tests unitaire complete et à jour.
Si tu peux garantir que toutes (ou du moins la plupart de) tes fonctions réagissent exactement de la manière dont elles sont sensées réagir (grace à tes tests unitaires), tu peux déjà réduire ta recherche aux seules fonctions pour lesquelles tu n'as pas cette garantie (qu'il faudrait arriver à donner, soit dit en passant).
Ce ne sont pas les commentaires qui t'aideront dans ce cas là. Bien au contraire, ils te ralentiront sans doute bien d'avantage, pour toute une série de raison (dont l'obsolescence dont ils risquent de faire preuve)"Sauf si c'est bien fait", penseras-tu. Mais si ce jour-là on se rend compte que c'est mal fait ?
Dans quel abîme se trouve t-on alors ?
On le répète à l'envi: le premier destinataire d'un code n'est pas le compilateur -- comme on pourrait le croire -- mais un lecteur humain.
Hé bien, ca, ca sous-entend qu'un code doit être construit comme un bon roman ou comme une bonne nouvelle: on ne doit pas avoir à réfléchir plus d'une demi seconde pour arriver à le comprendre.
Mais quand on en arrive à se dire qu'un commentaire "devrait aider la compréhension", c'est la preuve (je dirais presque par l'absurde) du fait que l'on n'a échoué à garantir cette qualité essentielle du code. Et cela ne fait qu'appliquer un emplâtre sur une jambe de bois, car, au mieux, il faudra que le lecteur "retrouve" le commentaire pour arriver à se dire "ah oui, c'est ca qu'on avait dit", au pire, le commentaire n'aura pas été mis à jour en même temps que le code, et l'information qu'il donnera sera -- au mieux -- purement et simplement erronée. Ce qui n'aidera de toutes façons pas à la compréhension.
De plus, le code est quand même malgré tout (faut-il le rappeler ) destiné dans un second temps au compilateur qui ignorera purement et simplement les commentaires. On peut donc écrire les plus monumentales conneries sous forme de commentaire, elles n'auront de toutes manières aucun impact sur la traduction effectuée par le compilateur (ou par l'interpréteur, selon le langage).
Sauf que, ces conneries, nous les aurons lues dans un premier temps. Et elles auront forcément eu un impact sur notre perception du problème. Et si c'étaient des conneries, parce que le commentaire "n'est pas à jour", cet impact ne pourra pas être autre chose que négatif.
Si bien que, il n'y a pas trente-six solutions au final: ce qui compte pour le compilateur, c'est le code hé bien ce qui doit compter pour le lecteur, c'est aussi le code. Et uniquement le code. Il n'y a aucune raison de faire en sorte que les deux protagonistes dans cette histoire puissent avoir des "sources d'informations" différentes. Car c'est quand on commence à se baser sur des sources d'informations différentes que les problèmes commencent à arriver: on trouvera toujours une source qui dit A alors que l'autre dit B.
Eviemment, cela nous oblige à nous poser une autre question: Comment faire pour qu'une même source d'informations (le code et rien que le code) soit aussi bien compréhensible par l'humain que par le compilateur Car, il n'y a rien à faire, on n'est décidément pas fait pareil.
Mais la réponse à cette question est toute simple: il faut que le code soit expressif. Plus le code sera expressif, plus l'humain aura facile à le lire et à le comprendre. Quant au compilateur, lui, il s'en fout pas mal: il fera ce qu'on lui dit quoi qu'il arrive.
Maintenant, tu demandes comment déterminer qu'un code est assez expressif... Hé bien, c'est tout simple: si une seule personne ayant à voir avec le code vient à poser une seule question concernant le code qu'elle lit, c'est qu'on a foiré notre coup, et qu'il faut le rendre plus expressif encore. Et ce n'est donc pas moi, l'auteur du code, qui dit que mon code est beau et expressif, c'est le reste de l'équipe, du débutant au vieux briscard, qui confirme qu'ils arrivent à comprendre le code sans avoir d'effort particulier à faire. Cela s'appelle la revue par les paires.
Mais, grâce à cette confirmation, je peux dormir sur mes deux oreilles: s'il y a une erreur dans mon code (je ne suis qu'un humain, j'en fais aussi), je sais que n'importe qui reprenant mon code arrivera à en déterminer l'origine et donc à la corriger.
Maintenant, je suis le premier à le reconnaître: ca demande un travail de dingue d'arriver à produire un code suffisamment expressif que pour qu'il puisse être compris sans avoir le moindre effort à faire. Mais c'est le boulot des développeurs, et ils sont grâcement payés pour le faire. Ce qui devrait être une raison supplémentaire (si beson en était) pour qu'ils le fassent correctement.
Partager