Le code est déjà écrit et les efforts sont dépensés
C'est également inutile. Si vous ne l'utilisez pas pour quoi que ce soit, il est (par définition) inutile, peu importe ce qu'il fait ou les efforts qui y ont été consacrés.
Le code peut être testé sur un environnement syntétique et réel
Si c'est inutile, c'est toujours inutile même si vous avez des tests dessus. Si le code est inutile, les tests devraient également être inutiles (donc garder le code commenté là, crée une ambiguïté - conservez-vous les tests? Si vous aviez le code client du code commenté, commentez-vous également le code client? )
S'il est bien organisé (groupé, package séparé, faiblement couplé, etc.), cela ne vous dérange pas sur l'analyse globale du code ou la refactorisation
Non. Tous vos outils (contrôle de source, analyse statique, extracteur de documentation, compilateur, etc.) fonctionneront plus lentement, car ils doivent traiter plus de données (et une partie plus ou moins grande de ces données est du bruit).
Si le code n'est pas bien organisé en revanche, il gâchera l'analyse statique, la refactorisation et tout autre.
Vous introduisez du bruit dans l'entrée de vos outils et espérez qu'ils y feront face correctement.
Et si votre outil d'analyse statique calcule un rapport commentaires / code? Vous venez de tout gâcher, avec quelque chose qui était pertinent jusqu'à hier (ou chaque fois que le code était commenté).
Le plus pertinent de tous, les blocs de code commentés entraînent des retards dans la compréhension du code pour la maintenance et le développement ultérieur et ces retards coûtent presque toujours cher. Posez-vous la question suivante: si vous avez besoin de comprendre l'implémentation d'une fonction, que préférez-vous regarder? deux lignes de code clair, ou deux lignes de code et vingt-six autres commentaires qui ne sont plus d'actualité?
Le code peut être utilisé à l'avenir
Si c'est le cas, vous le trouverez dans le SCM de votre équipe.
Si vous utilisez un SCM compétent et que vous comptez sur lui pour conserver le code mort (au lieu d'encombrer la source), vous devriez voir non seulement qui a supprimé ce code (auteur de la validation), mais pour quelle raison (message de validation), et quelle autre des modifications ont été apportées avec lui (le reste des différences pour ce commit).
Une fois supprimé, l'auteur peut se sentir mal à l'aise
Alors?
Vous êtes (je suppose) toute une équipe de développeurs qui est payée pour créer le meilleur logiciel que vous savez faire, pas "le meilleur logiciel que vous savez faire sans blesser les sentiments de X".
C'est une partie de la programmation, que la plupart du code écrit sera finalement jeté; par exemple, Joel Spolsky a déclaré à un moment donné que pour son entreprise, environ 2% du code écrit est produit.
Si vous privilégiez l'ego des développeurs à la qualité de la base de code, vous sacrifierez la qualité de votre produit, pour ... quoi exactement? Préserver 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 de laisser du code commenté dans la source, et c'est un cas très spécifique: lorsque le code est écrit sous une forme étrange / non intuitive et que la manière propre de le réécrire ne le fait pas travailler pour une raison vraiment subtile. Cela ne doit également être appliqué qu'après une tentative répétée pour corriger le problème et chaque fois que la tentative a réintroduit le même défaut. Dans un tel cas, vous devez ajouter le code intuitif commenté en tant que commentaire et expliquer pourquoi cela ne fonctionne pas (afin que les futurs développeurs ne tentent pas à nouveau le même changement):
// 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);