Est-ce une bonne pratique de commenter le code qui est supprimé ? Par exemple :
// Code to do {task} was removed by Ajahn on 10/10/08 because {reason}.Lors d'une évaluation par les pairs, un membre de mon groupe de développeurs a fait remarquer que nous devrions commenter les lignes de code à supprimer. J'ai pensé que cette suggestion était terrible, car elle encombre le code de commentaires inutiles. Lequel de nous deux a raison ?
En général, le code qui est supprimé ne doit pas être commenté, précisément parce qu'il encombre la base de code (et pourquoi commenter quelque chose qui n'existe pas ?).
C'est à votre système de suivi des défauts ou à vos outils de gestion du contrôle du code source que ces commentaires doivent être adressés.
Toutefois, dans certaines situations, vous pouvez dire "J'ai supprimé ce qui semble devoir aller ici à cause de ceci", surtout si ce n'est pas intuitif. Ces situations sont toutefois TRÈS rares.
Dans certaines situations (rares), il est préférable de commenter le code (au lieu de l'effacer). En voici une.
J'avais une ligne de code qui me semblait bonne et nécessaire. Plus tard, je me suis rendu compte qu'elle était inutile et nuisible. Au lieu de supprimer la ligne, je l'ai commentée, en ajoutant un autre commentaire : "La ligne ci-dessous est erronée pour telle ou telle raison". Pourquoi ?
Car je suis sûr que le prochain lecteur du code pensera d'abord que pas Cette ligne est une erreur et nous essaierons de la réintroduire. (Je ne m'attends pas à ce qu'il consulte d'abord le contrôle des sources. J'ai besoin d'ajouter un commentaire pour l'avertir de cette situation délicate ; et avoir une ligne erronée et la raison pour laquelle elle est erronée s'est avéré être la meilleure façon de le faire.
Pourquoi ne pas simplement ajouter un commentaire à la méthode, à la classe ou à la fonction, etc. indiquant de manière méta ce qui a été essayé auparavant et pourquoi cela n'a pas fonctionné, peut-être avec un pointeur vers une révision donnée, sans laisser le "code" dans le fichier source ? C'est ce que j'aurais tendance à faire.
Comme il ne s'agit que d'une ligne de code, toute méta-description serait plus longue et encombrerait davantage le code.
Pourquoi ne pas simplement inclure un test pour le comportement brisé que la ligne a causé dans les tests unitaires ?
Je suis d'accord pour dire que ce n'est pas une bonne idée de laisser des codes supprimés dans les commentaires.
L'historique du code doit être consulté par le biais d'un système de contrôle des versions, qui permet de retrouver les anciens codes ainsi que la raison pour laquelle ils ont été supprimés.
Oui, car les développeurs consultent toujours l'historique des versions de chaque fichier avant de le modifier. La solution la plus "correcte" doit être modifiée pour tenir compte de la nature humaine.
Cela dépend de la raison du retrait.
Je considère les commentaires comme des indications pour les personnes chargées de la maintenance du code à l'avenir. Si l'information selon laquelle le code existait mais a été supprimé peut être utile à une personne chargée de la maintenance du code (peut-être comme un signe "ne faites pas cela"), alors elle doit être présente.
Sinon, l'ajout de commentaires détaillés avec des noms et des dates pour chaque modification du code rend l'ensemble illisible.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
