Il est évident qu'il est nécessaire (indispensable) de commenter son code, de manière à faire apparaître l'intention derrière le code.
Du coup je trouve que ta question ne se pose pas.
Si tu le permets, la question qui me semble plus intéressante est : Comment inciter (obliger) les développeurs à commenter leur code de manière pertinente ?
Certains éditeurs ont bien compris l'enjeu et proposent des métriques de mesure de nombre de lignes de commentaires rapporté au nombre total de lignes de source. Avec une alerte en dessous d'un certain %. Je pense à CAST par exemple.
Mais bien souvent, ça sert juste à être relu 1 fois tous les 5 ans par un architecte et on n'en tirera rien.
Côté documentation (et pas commentaire), je trouve que Java a proposé de bonnes pistes :
- modèle type de documentation : Javadoc
- IDE générant automatiquement des prototypes de documentation de code
- mesure de la présence et l'exhaustivité de la documentation dans des outils d'analyse statique (Sonar, checkstyle…)
L'écosystème propose ce qu'il faut pour mesurer et suivre la qualité de code.
Par la suite les IDE et outils utilisés dans le monde Java se sont étendus aux autres langages (je pense à Eclipse, Sonar qui sont utilisés sur d'autres langages).
Doxygen a permis à peu près la même chose que Javadoc mais sans être lié au langage Java.
Est il possible d'imaginer la même chose avec les commentaires ?
Actuellement je ne connais pas de meilleur moyen de faire prendre conscience à un développeur qu'il faut commenter que de lui donner à maintenir du vieux code, ayant subi de nombreuses modifications (pas toujours bien commentées).
# Comment inciter à commenter
Posté par Pierre Tramonson . En réponse au journal To comment or not to comment. That is the question.. Évalué à 1.
Il est évident qu'il est nécessaire (indispensable) de commenter son code, de manière à faire apparaître l'intention derrière le code.
Du coup je trouve que ta question ne se pose pas.
Si tu le permets, la question qui me semble plus intéressante est : Comment inciter (obliger) les développeurs à commenter leur code de manière pertinente ?
Certains éditeurs ont bien compris l'enjeu et proposent des métriques de mesure de nombre de lignes de commentaires rapporté au nombre total de lignes de source. Avec une alerte en dessous d'un certain %. Je pense à CAST par exemple.
Mais bien souvent, ça sert juste à être relu 1 fois tous les 5 ans par un architecte et on n'en tirera rien.
Côté documentation (et pas commentaire), je trouve que Java a proposé de bonnes pistes :
- modèle type de documentation : Javadoc
- IDE générant automatiquement des prototypes de documentation de code
- mesure de la présence et l'exhaustivité de la documentation dans des outils d'analyse statique (Sonar, checkstyle…)
L'écosystème propose ce qu'il faut pour mesurer et suivre la qualité de code.
Par la suite les IDE et outils utilisés dans le monde Java se sont étendus aux autres langages (je pense à Eclipse, Sonar qui sont utilisés sur d'autres langages).
Doxygen a permis à peu près la même chose que Javadoc mais sans être lié au langage Java.
Est il possible d'imaginer la même chose avec les commentaires ?
Actuellement je ne connais pas de meilleur moyen de faire prendre conscience à un développeur qu'il faut commenter que de lui donner à maintenir du vieux code, ayant subi de nombreuses modifications (pas toujours bien commentées).