Pour savoir si on doit commenter ou pas son code source, je me réfère toujours à un code de référence (par sa visibilité et l ́échelle des déploiements) : le noyau Linux.
Dans le code du noyau Linux, on vas trouver le code qui gère la mémoire virtuelle, qui gère le PCI, les interruptions, les périphériques USB, j ́en passe et des meilleurs. Je n ́y ai fait que de (trop) rares modifications pour m ́y attarder.
Ce que l ́on sait moins, c ́est qu ́il y a aussi beaucoup de code accessoire, comme toute l ́infrastructure qui permet de configurer et compiler le noyau.
Et là, par contre, ça commence à devenir, comment dire, pour le moins folklo. Je conseille à tout un chacun de jeter un œil sur le code de kconfig pour voir l ́étendue des dégâts dans un code non commenté, et ayant évolué de manière organique au fil du temps (10 ans au moins).
Voilà, j ́espère garder quelques cheveux après mes pérégrinations dans ce code… ;-)
# Allez, un exemple concret...
Posté par ymorin . En réponse au journal To comment or not to comment. That is the question.. Évalué à 3.
Pour savoir si on doit commenter ou pas son code source, je me réfère toujours à un code de référence (par sa visibilité et l ́échelle des déploiements) : le noyau Linux.
Dans le code du noyau Linux, on vas trouver le code qui gère la mémoire virtuelle, qui gère le PCI, les interruptions, les périphériques USB, j ́en passe et des meilleurs. Je n ́y ai fait que de (trop) rares modifications pour m ́y attarder.
Ce que l ́on sait moins, c ́est qu ́il y a aussi beaucoup de code accessoire, comme toute l ́infrastructure qui permet de configurer et compiler le noyau.
Et là, par contre, ça commence à devenir, comment dire, pour le moins folklo. Je conseille à tout un chacun de jeter un œil sur le code de kconfig pour voir l ́étendue des dégâts dans un code non commenté, et ayant évolué de manière organique au fil du temps (10 ans au moins).
Voilà, j ́espère garder quelques cheveux après mes pérégrinations dans ce code… ;-)
Hop,
Moi.