Il faut en effet être nuancé. Une partie des commentaires peuvent être connu avant l'implémentation finale, ce sont les restes du peusdo code quand ils sont nécéssaires. Cependant ce que tu laisseras dépendra du résultat final.
Après les commentaires sur le code lui même, tu vas t'en rendre compte de leur utilité compte en écrivant. "C'est évident pour moi qu'on n'a pas besoin besoin de tester pour un int overflow mais je le signale au lecteur".
Après la plupart des commentaires concernent la logique métier et sont ajoutés après la v1 et sont des bugfix et de l'évolution du code. Généralement la v1 est simple et n'a pas besoin de beaucoup de commentaires car elle a été designée de 0 et que le code peut exprimer assez précisément la pensée. Les 10 autres versions après vont rajouter des options, gérer les problèmes de compats, subir du perf tuning, fournir de nouvelle feature etc.
Bref tu ne mets pas un commentaire pour dire que tu as mal utiliser une lib, c'est débile. Par contre tu laisses des indications comme quoi "On fait ca par ce que": "On attrape cette erreur par ce que sur le système X version Y il peut se produire ca", "On utilise cette option plutôt qu'une autre par que la v21 à un bug", "On ne touche pas a ce pointeur par ce que y'a une action asynchrone qui l'utilise", "On choisi cette approche par ce qu'un utilisateur à rapporter un problème de performance dans la version d'avant", "attention si tu changes cette variable tu changes aussi le comportement de ca" etc. C'est pour ca que les réécritures sont rarement des succès, repartir de 0 ca veut dire remettre sa maturité à 0 et donc perdre son avance.
[^] # Re: Commenter l'intention
Posté par ckyl . En réponse au journal To comment or not to comment. That is the question.. Évalué à 6. Dernière modification le 23 avril 2013 à 14:34.
Il faut en effet être nuancé. Une partie des commentaires peuvent être connu avant l'implémentation finale, ce sont les restes du peusdo code quand ils sont nécéssaires. Cependant ce que tu laisseras dépendra du résultat final.
Après les commentaires sur le code lui même, tu vas t'en rendre compte de leur utilité compte en écrivant. "C'est évident pour moi qu'on n'a pas besoin besoin de tester pour un int overflow mais je le signale au lecteur".
Après la plupart des commentaires concernent la logique métier et sont ajoutés après la v1 et sont des bugfix et de l'évolution du code. Généralement la v1 est simple et n'a pas besoin de beaucoup de commentaires car elle a été designée de 0 et que le code peut exprimer assez précisément la pensée. Les 10 autres versions après vont rajouter des options, gérer les problèmes de compats, subir du perf tuning, fournir de nouvelle feature etc.
Bref tu ne mets pas un commentaire pour dire que tu as mal utiliser une lib, c'est débile. Par contre tu laisses des indications comme quoi "On fait ca par ce que": "On attrape cette erreur par ce que sur le système X version Y il peut se produire ca", "On utilise cette option plutôt qu'une autre par que la v21 à un bug", "On ne touche pas a ce pointeur par ce que y'a une action asynchrone qui l'utilise", "On choisi cette approche par ce qu'un utilisateur à rapporter un problème de performance dans la version d'avant", "attention si tu changes cette variable tu changes aussi le comportement de ca" etc. C'est pour ca que les réécritures sont rarement des succès, repartir de 0 ca veut dire remettre sa maturité à 0 et donc perdre son avance.