Sinon c'est aussi le risque de voir apparaître avec le temps un décalage entre le code et les commentaires (et là ça devient vraiment galère)
Je commence à me dire que c'est qu'il faut redécouper la fonction. Je suis pour les commentaires dans les fonctions, mais de plus en plus souvent je me dis que quand tu as un commentaire qui doit décrire une sous partie de ta fonction, c'est que ça doit en être une nouvelle (bonus : tu as un commentaire normalisé (doxygen, javadoc) qui décrit les entrées, les sorties, les cas d'erreur, bonus+ : cette nouvelle méthode deviendra testable unitairement, bonus++ : en plus de ton code, en plus de ton commentaire, tu aura des tests qui décriront son comportement). C'est rébarbatif et comme c'est comme tout il faut pas le respecter pour le respecter, mais plutôt se poser la question.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: /* commentaire ou documentation inline ? */
Posté par barmic . En réponse au journal To comment or not to comment. That is the question.. Évalué à 9.
Je commence à me dire que c'est qu'il faut redécouper la fonction. Je suis pour les commentaires dans les fonctions, mais de plus en plus souvent je me dis que quand tu as un commentaire qui doit décrire une sous partie de ta fonction, c'est que ça doit en être une nouvelle (bonus : tu as un commentaire normalisé (doxygen, javadoc) qui décrit les entrées, les sorties, les cas d'erreur, bonus+ : cette nouvelle méthode deviendra testable unitairement, bonus++ : en plus de ton code, en plus de ton commentaire, tu aura des tests qui décriront son comportement). C'est rébarbatif et comme c'est comme tout il faut pas le respecter pour le respecter, mais plutôt se poser la question.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)