Les commentaires, eux, n'ont pratiquement rien (juste la revue de code). Ce qui fait que les commentaires, qui eux sont très peu analysés, sont généralement la partie du code qui contient le plus de bug par ligne de commentaire. (par bug, j'entends commentaire qui ne dit pas ce que devrait faire le code)
Et si un commentaire est erroné, aucun outils ou tests ne va te dire qu'il est faux.
Au risque de me répéter, quand on parle de commenter son code, ce n’est pas de mettre des commentaires qui ne servent à rien ...aux devs futurs, comme par exemple
ma_variable = ma_variable + 1 // incrémentation de ma variable Il est tout à fait logique que les commentaires ne servent aux outils ...parce-que c’est à destination des humains, et c’est bien que ça serve à la revue de code. Exemple de commentaire tout con qui que je trouve fort utile :
// dans l'urgence et parce-que le tableau ne contient que 10 entiers,
// on utilise le tri par bulle (et puis faut livrer dans 1h.)
// par ailleurs, les position paires du tableau valent toujours zéro.
fonction trier_tableau(T est tableau):
... Que tes outils sachent détecter dans le code qu’il y a un pointeur initialisé dans la fonction et puis oublié, c’est OK. Mais ces outils ne sauront pas te dire quelle implémentation choisir ou pourquoi telle optimisation est bonne ou pas.
Et quand t'a déjà passé une demi-journée à te faire toute la Documentation d'une bibliothèque, car un commentaire te dit d'absolument appelle une autre fonction avant d'appeler celle dont tu as besoins, pour au final en lisant le code de la bibliothèque te rendre compte que le commentaire aurait juste dû être supprimé, car il concernait une ancienne version de la bibliothèque.
Bah, tu regardes les commentaires d'un autre œil.
Les bons commentaires font partie du code. Les deux évoluent ensemble...
J’ai déjà vu l’inverse aussi : tu passes des heures à essayer de comprendre un code qui ne fait pas du tout ce que dit le commentaire et au final tu apprends que la personne qui a modifié le code a voulu régler un cas pour lui ...et fatalement en partant sur son unique use-case et son refactoring complet en se croyant plus malin que tout le monde, bah il a passé à la trappe tous les autres cas qui ont été évité avant lui. Aujourd’hui, on aurait des test unitaires qui auraient permis de rattraper la bourde (ou juste 90%) ; et ça fait partir de documenter le code (je sais la documentation ne se fait pas par les commentaires ici mais c’est pour dire à ceux qui s’insurgent en voyant qu’il faut documenter le code que voilà.)
Oui, quand l’architecte fait des modifications sans mettre à jour les plans, tu regardes les plans d’un autre œil. Mais la règle ne devient pas qu’il faut bannir les plans ; plutôt les architectes qui travaillent à la va-comme-j'te-pousse. De même, juste mentionner les latrines sur les plans de la baraque est suffisant, pas besoin d’indiquer chaque carreau individuel ; et le jour où on rase cette pièce on laisse pas non plus croire sur le plan qu’elle existe.
"It is seldom that liberty of any kind is lost all at once." ― David Hume
[^] # Re: Complètement crétin !
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au journal Comment briller auprès de la gent féminine dans « le monde de la tech ». Évalué à 6.
Au risque de me répéter, quand on parle de commenter son code, ce n’est pas de mettre des commentaires qui ne servent à rien ...aux devs futurs, comme par exemple
ma_variable = ma_variable + 1 // incrémentation de ma variable
// dans l'urgence et parce-que le tableau ne contient que 10 entiers,
// on utilise le tri par bulle (et puis faut livrer dans 1h.)
// par ailleurs, les position paires du tableau valent toujours zéro.
fonction trier_tableau(T est tableau):
...
Les bons commentaires font partie du code. Les deux évoluent ensemble...
J’ai déjà vu l’inverse aussi : tu passes des heures à essayer de comprendre un code qui ne fait pas du tout ce que dit le commentaire et au final tu apprends que la personne qui a modifié le code a voulu régler un cas pour lui ...et fatalement en partant sur son unique use-case et son refactoring complet en se croyant plus malin que tout le monde, bah il a passé à la trappe tous les autres cas qui ont été évité avant lui. Aujourd’hui, on aurait des test unitaires qui auraient permis de rattraper la bourde (ou juste 90%) ; et ça fait partir de documenter le code (je sais la documentation ne se fait pas par les commentaires ici mais c’est pour dire à ceux qui s’insurgent en voyant qu’il faut documenter le code que voilà.)
Oui, quand l’architecte fait des modifications sans mettre à jour les plans, tu regardes les plans d’un autre œil. Mais la règle ne devient pas qu’il faut bannir les plans ; plutôt les architectes qui travaillent à la va-comme-j'te-pousse. De même, juste mentionner les latrines sur les plans de la baraque est suffisant, pas besoin d’indiquer chaque carreau individuel ; et le jour où on rase cette pièce on laisse pas non plus croire sur le plan qu’elle existe.
"It is seldom that liberty of any kind is lost all at once." ― David Hume