Si le commentaire était à jour, s'il avait été lu, s'il avait été mis au bon niveau, s'il avait été compris,... Oui.
Mais c'est une question de documentation par les tests, c'est aussi une question de méthodologie, si tu applique le TDD tu n'aura pas touché au code de production.
L'un n'interdit pas complètement l'autre, mais l'un est obligatoire l'autre est optionnel et induit un coup qui me paraît bien plus important que son gain (on ne passe pas des heures sans lire les tests ou les lancer).
Généralement on le met quand le bug appel à un code vraiment WTF.
[^] # Re: Rule 8: Add comments when fixing bugs
Posté par barmic 🦦 . En réponse au lien Best practices for writing code comments. Évalué à 2. Dernière modification le 31 décembre 2021 à 11:03.
Si le commentaire était à jour, s'il avait été lu, s'il avait été mis au bon niveau, s'il avait été compris,... Oui.
Mais c'est une question de documentation par les tests, c'est aussi une question de méthodologie, si tu applique le TDD tu n'aura pas touché au code de production.
L'un n'interdit pas complètement l'autre, mais l'un est obligatoire l'autre est optionnel et induit un coup qui me paraît bien plus important que son gain (on ne passe pas des heures sans lire les tests ou les lancer).
Généralement on le met quand le bug appel à un code vraiment WTF.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll