Le Code est déjà écrit, et des efforts sont passé
Il est également inutile. Si vous ne l'utilisez pas pour rien, c'est (par définition) inutile, peu importe ce qu'il fait ou comment beaucoup d'efforts ont été consacrés.
Le Code peut être testé sur syntetical et environnement réel
Si c'est inutile, il est encore inutile, même si vous avez des tests sur elle. Si le code est inutile, les tests pour les il devrait inutiles (ainsi garder le code commenté il y, crée l'ambiguïté - gardez-vous des tests? si vous aviez code client, le code commenté, avez-vous commenter le code client ainsi?)
S'ils sont bien organisés (groupés, paquet séparé, faiblement couplées, etc), il ne vous perturbe sur l'ensemble de l'analyse de code ou de refactoring
De ne pas faire. Tous vos outils (source de contrôle, de l'analyse statique, de la documentation, une hotte, un compilateur, etc) fonctionnera plus lentement, parce qu'ils ont à traiter plus de données (et d'une plus grande ou plus petite partie de ces données est le bruit).
Si le code n'est pas bien organisé sur l'autre main, il gâchera l'analyse statique, refactoring, et tout les autres.
Vous êtes d'introduire du bruit de vos outils de saisie et en espérant qu'ils réagissent correctement avec lui.
Que faire si votre outil d'analyse statique calcule un commentaires/code ratio? Vous avez juste a tout fait foiré, avec quelque chose de pertinent, jusqu'à hier (ou chaque fois que le code a été commenté).
La plupart de tous, ont commenté les blocs de code à introduire des retards dans la compréhension du code pour le maintien et le développement et que de tels retards presque toujours le coût d'un lot. Demandez-vous ceci: Si vous avez besoin de comprendre la mise en œuvre d'une fonction, que feriez-vous plutôt à regarder? deux lignes d'un code clair, ou deux lignes de code et un autre vingt-six des commentaires qui ne sont plus réelle?
Le Code peut être utilisé à l'avenir
Si elle l'est, vous le trouverez dans votre équipe SCM de choix.
Si vous utilisez un compétent SCM et de compter sur elle pour garder le code mort (au lieu d'encombrer la source), vous devriez voir non seulement la personne qui a supprimé ce code (commit auteur), mais pour quelle raison (message de commit), et ce que d'autres changements ont été apportés avec elle (le reste de la diff pour valider).
Quand il est supprimé, l'auteur peut se sentir mal à l'aise
De la sorte?
Vous êtes (je suppose) de toute une équipe de développeurs qui obtient payé pour faire le meilleur logiciel que vous savez comment, et non pas "le meilleur logiciel que vous savez comment sans blesser les sentiments de X".
C'est une partie de la programmation, que la plupart de code écrit en fin de compte être écarté; par exemple, Joel Spolsky dit à un certain point, que pour son entreprise, environ 2% de code écrit, voit la production.
Si vous la priorité de l'ego de développeurs sur la qualité de la base de code, vous serez sacrifier la qualité de votre produit, pour ... quoi exactement? La préservation de l'immaturité de vos collègues développeurs? Protéger les attentes irréalistes de vos collègues?
Edit: j'ai vu une raison valable pour laisser en commentaire le code dans la source, et c'est un cas très précis: lorsque le code est écrit dans un étrange/un-formulaire intuitif et le propre façon de ré-écriture, il ne fonctionne pas pour une très subtile raison. Cela devrait également être appliquée qu'après une nouvelle tentative a été faite pour corriger le problème et à chaque fois que la tentative a présenté de nouveau le même défaut. Dans un tel cas, vous devez ajouter le commentaire intuitive code dans un commentaire, et d'expliquer pourquoi il n'a pas de travail (et donc les futurs développeurs de ne pas tenter la même modification à nouveau):
// note by <author>: the X parameter here should normally
// be a reference:
// void teleport(dinosaur& X);
// but that would require that we raise another dinosaur and
// kill it every twelve hours
// as such, the parameter is passed by value
void teleport(dinosaur X);
