Je suis d'accord avec toi, c'est le but. Mais sur une base de code sérieuse même en v1 je n'ai jamais vu un état ou l'on pouvait se passer de commentaires. Ceux qui l'ont fait mentaient, et ceux qui ont maintenu ont pleuré. Après ca doit beaucoup dépendre des domaines et du type de produit. Quand ca peut être simple et évident, aucune raison de faire compliqué.
Le commentaire interne ca sert à expliquer les cas tordus du fonctionnel ou une approche. Un compilo sérieux aide, mais il reste des choses à expliquer pour aider le lecteur (ou expliquer pourquoi ca a fini comme ca et pas autrement). Exemple à la con, un comportement spécifique à une plateforme qu'on t'a remonté. Si tu ne laisses pas une trace de pourquoi tu fais ca, le lecteur n'a aucune chance de le deviner jusqu'à ce qu'il réintroduise le bug et qu'un nouveau BR arrive.
Souvent plus une code base à veilli et murri plus il y a des commentaires internes. Car les choses se sont fait affiner et un million de cas tordu sont gérés ce qui n'est pas forcément le cas d'une base neuve. Idem quand tu dois gérer la compatibilité.
[^] # Re: /* commentaire ou documentation inline ? */
Posté par ckyl . En réponse au journal To comment or not to comment. That is the question.. Évalué à 4.
Je suis d'accord avec toi, c'est le but. Mais sur une base de code sérieuse même en v1 je n'ai jamais vu un état ou l'on pouvait se passer de commentaires. Ceux qui l'ont fait mentaient, et ceux qui ont maintenu ont pleuré. Après ca doit beaucoup dépendre des domaines et du type de produit. Quand ca peut être simple et évident, aucune raison de faire compliqué.
Le commentaire interne ca sert à expliquer les cas tordus du fonctionnel ou une approche. Un compilo sérieux aide, mais il reste des choses à expliquer pour aider le lecteur (ou expliquer pourquoi ca a fini comme ca et pas autrement). Exemple à la con, un comportement spécifique à une plateforme qu'on t'a remonté. Si tu ne laisses pas une trace de pourquoi tu fais ca, le lecteur n'a aucune chance de le deviner jusqu'à ce qu'il réintroduise le bug et qu'un nouveau BR arrive.
Souvent plus une code base à veilli et murri plus il y a des commentaires internes. Car les choses se sont fait affiner et un million de cas tordu sont gérés ce qui n'est pas forcément le cas d'une base neuve. Idem quand tu dois gérer la compatibilité.