La plupart du temps dans la documentation, ce qui importe, c'est les données et leur signification, l'explication grossière de l'objectif des fonctions (un très bon article sur LMF en parle)
Les commentaires en plein code (ou l'inverse, d'après ce que j'ai compris de Mx) tendent plutot à rendre le code abscons ; pourquoi vouloir expliquer extensivement avec un langage humain un code naturellement sans ambiguité (S'il ne l'est pas, c'est par la qu'il faut commencer : l'architecture).
Je vois 2 effets de bord graves à ce principe :
* Plus on explique le code, moins on éprouve le besoin de le rendre clair à la source
* Le code perdu dans la documentation, bonjour le debug. Perso, je débuggue visuellement, et la proximité des lignes de codes y joue pour beaucoup.
C'est une curiosité intéressante, mais pas applicable aux langages actuels.
# Pas efficace
Posté par Jean-Noël Avila . En réponse à la dépêche Mx: outil de documentation de code source. Évalué à 1.
Les commentaires en plein code (ou l'inverse, d'après ce que j'ai compris de Mx) tendent plutot à rendre le code abscons ; pourquoi vouloir expliquer extensivement avec un langage humain un code naturellement sans ambiguité (S'il ne l'est pas, c'est par la qu'il faut commencer : l'architecture).
Je vois 2 effets de bord graves à ce principe :
* Plus on explique le code, moins on éprouve le besoin de le rendre clair à la source
* Le code perdu dans la documentation, bonjour le debug. Perso, je débuggue visuellement, et la proximité des lignes de codes y joue pour beaucoup.
C'est une curiosité intéressante, mais pas applicable aux langages actuels.