Devrais-je supprimer le code non référencé?

Je travaille sur une base de code de taille moyenne (100 000 lignes), elle est relativement récente (moins d'un an) et offre une bonne couverture de tests unitaires.

Je n'arrête pas de rencontrer des méthodes qui ne sont plus utilisées nulle part ou qui ne sont référencées que dans des tests unitaires qui testent uniquement cette méthode spécifique.

Devrais-je supprimer ce code si je suis certain qu'il n'est plus nécessaire?

Raisons pour l'enlever:

• Moins de code, moins de bugs
• Moins de code est plus facile à digérer pour les autres
• Il est toujours sous contrôle de source

Raisons pour le garder:

• Peut être utilisé comme référence
• Il peut être utile parfois
• Il a peut-être été écrit pour "compléter" la fonctionnalité d'une classe

La plupart de vos raisons pour le garder sont totalement hors de propos, en termes simples. Si le code n'est pas utilisé, jetez-le à la poubelle: tout avantage lié à sa conservation peut dériver de manière triviale du contrôle de source. Tout au plus, laissez un commentaire indiquant dans quelle révision le trouver.

Tout simplement, plus tôt vous coupez le code, plus vite vous ne perdez pas de temps à le maintenir, à le compiler et à le tester. Ces avantages dépassent largement les avantages triviaux que vous avez décrits, qui peuvent tous être dérivés du contrôle de source.

Toutes les raisons pour l'enlever sont valables.

Raisons pour le garder:

• Peut être utilisé comme référence
• Il peut être utile parfois
• Il a peut-être été écrit pour "compléter" la fonctionnalité d'une classe

Toutes ces raisons pour le garder seront gérées par le contrôle de source. Supprimez-le du code live et vous pourrez le récupérer si nécessaire.

Le code non référencé revient à conserver ces piles un peu à plat, au cas où vous en auriez besoin un jour pour une lampe de poche.

Tant que vous utilisez une sorte de contrôle de version, je dirais de le supprimer du code dynamique et d'utiliser l'historique des versions au cas où il s'avérerait utile.

La seule bonne raison de garder le code qui n'est pas utilisé actuellement est si cela fait partie d'un module autonome: Bien que certaines parties du code ne soient peut-être pas utilisées pour le moment, il est fort possible qu'elles le soient utilisé à l'avenir.

Cela peut être particulièrement vrai pour une bibliothèque que vous utilisez dans différents projets: vous ne voulez pas continuer à lancer des morceaux de code, selon ce dont vous avez besoin pour un projet spécifique: je trouve cela fastidieux et sujet aux erreurs.

Mon approche est la suivante: (1) si vous l’utilisez une fois, ne gardez que ce dont vous avez réellement besoin; (2) si vous l'utilisez deux fois, copiez-le et adaptez-le à la deuxième utilisation; (3) si vous l'utilisez plus de deux fois, créez-en un module stable et bien défini, et utilisez-le selon vos besoins.

Résumer: je jetterais tout le code inutilisé à moins qu’il fasse partie d’un module généraliste que vous avez conçu en tant que tel et que vous savez que vous allez le réutiliser plusieurs fois.

Remarque : Bien entendu, une solution encore plus propre consisterait à créer un projet distinct pour une bibliothèque et à ajouter une dépendance entre les projets.

En général, je m'inclinerais devant YAGNI à ce sujet. Si "vous n'en avez pas besoin", cela prend simplement de la place dans votre base de code, vos tests unitaires et vos assemblages. Vous en aurez peut-être besoin, mais vous aurez peut-être aussi besoin de le réécrire complètement car, d’ici au moment où vous aurez besoin de quoi que ce soit, beaucoup de choses peuvent changer.

Toutefois, cela change quelque peu lorsque vous écrivez un utilitaire ou une API destinée à la consommation générale. Tout comme vous ne pouvez jamais vous attendre à ce que les utilisateurs finaux du logiciel interagissent avec le logiciel de la manière que vous aviez prévue, vous ne pouvez jamais vous attendre à ce que les utilisateurs de votre code veuillent utiliser votre code exactement comme vous le souhaitez. Dans de tels cas, tant que vous pouvez justifier l'existence d'une méthode avec "c'est un moyen valide de vouloir interagir avec mon objet", alors elle devrait probablement y entrer, car même si vous n'en avez pas besoin, il y a de bonnes chances .

Étant donné que la base de code a moins d'un an, elle est probablement toujours en pleine mutation (oui?) - de sorte que la notion qu'il faudra peut-être ressusciter certains bits dans un proche avenir n'est pas déraisonnable.

Pour les éléments difficiles à obtenir correctement et qui semblent plus susceptibles d'être ressuscités, je les garderais un peu plus "en direct" que dans le contrôle de source. Les gens ne sauront pas / ne se souviendront pas de leur existence - dire "vous pouvez simplement le trouver dans le contrôle de code source" suppose que vous savez / vous rappelez que c'est là! Dans ce type de cas, envisagez la dépréciation (avec un témoin "assert (false)") ou la mise en commentaire.

Si le code est trivial et sans intérêt, je le jette simplement pour éliminer l'inertie inutile du système logiciel.

Pour les cadavres de code intéressants, j'utilise une archivebranche dans mes systèmes de contrôle de version.

"Peut être utilisé comme référence" Je n’aurais pas tendance à penser que c’est une bonne raison de laisser du code inutilisé. Souvent, seule une petite partie du code inutilisé démontre quelque chose d'intéressant. Il existe plusieurs façons de documenter et de stocker du code utile mais non utilisé.

Bien que le contrôle de version contienne un historique qui vous permettra facilement de restaurer des fonctionnalités particulières si vous décidez ultérieurement que le code est nécessaire, sachant que vous devez consulter l'historique de contrôle de version pour rechercher xy ou z auprès de qui sait quelle révision précédente peut être. un peu fastidieux, et est souvent négligé, sauf si vous avez une idée assez précise de ce que vous recherchez.

Le code peut être commenté avec une note indiquant quand il a été supprimé et pourquoi il n'a pas été simplement supprimé du code. Cependant, ceci est généralement considéré comme un mauvais style, et un code qui n'est pas utilisé ni maintenu correctement peut générer toutes sortes de bogues s'il n'est pas commenté plus tard. C'est donc généralement préférable comme étape de débogage / test temporaire en cours de refactoring à la mi-refonte. une façon de laisser le code de production.

Mon moyen préféré pour stocker le code supprimé, si cela semble utile à l'avenir, est de créer un document de référence secondaire contenant tous les différents morceaux de code utile supprimé. Chaque bloc de code est étiqueté avec une brève mention de son origine ou de tout autre élément pertinent à retenir, tel que le moment où il a été supprimé ou le numéro de révision où il figurait en dernier dans le code. Tout ce qui est supprimé, sauf "potentiellement utile", se trouve au même endroit, il est facile de le rechercher, mais ne nécessite pas d'effort constant de maintenance et de test continu (ce test est reporté à n'importe quel moment où le code est réintroduit).

Une bonne raison de conserver les méthodes inutilisées est la suivante: elles pourraient être utilisées sur d'autres branches / tags!

Explorez toutes vos branches et balises actives avant de les supprimer.

Si vous utilisez un système de contrôle de version, ne vous inquiétez pas des références futures, vous pouvez simplement voir à travers l'historique de ce code et trouver la partie supprimée. Si vous ne le faites pas et si vous pensez qu'il sera utilisé un jour, laissez-le simplement rester là, mais commentez-le avec une description expliquant pourquoi il est commenté.

Cependant, si vous êtes certain de ne plus l'utiliser, supprimez-le simplement . Je pense que les raisons que vous avez mentionnées sont assez simples pour que le code soit supprimé.

Mais s'il vous plaît avant de le retirer, assurez-vous qu'il n'est pas utilisé nulle part. Visual Studio dispose d'une fonctionnalité appelée Rechercher toutes les références qui recherche dans toute la solution et trouve toute référence à la variable, méthode, propriété, classe, interface, etc. en cours. Je m'assure toujours qu'aucune référence n'est en place avant de supprimer une partie de mon code.

J'ai eu assez souvent l'expérience de trouver une fonction qui semble correspondre exactement à ce dont j'ai besoin et de la croire pour fonctionner depuis qu'elle est en production depuis longtemps, seulement pour découvrir qu'elle n'a pas encore été utilisée plusieurs années. Le code qui n'est pas utilisé n'est pas maintenu et, même s'il a déjà fonctionné il y a des années, l'API a suffisamment changé pour que vous ne puissiez plus lui faire confiance.

Au mieux, vous finissez par passer beaucoup de temps à vous assurer qu'il fait toujours ce que vous voulez. Dans le pire des cas, cela semble fonctionner jusqu'à ce que vous obteniez un mauvais bug plus tard, et prenez plus de temps à le localiser car vous supposez que le code "testé en production" fonctionne, le problème doit donc se trouver ailleurs dans votre nouveau code. D'après mon expérience, il est presque toujours plus rapide d'écrire moi-même une nouvelle fonction.

Si vous le supprimez, mais que vous découvrez assez rapidement que vous en avez réellement besoin, cela se trouve dans le contrôle de source. Si vous n'en avez pas besoin jusqu'à ce que le temps soit écoulé et que vous ne vous souveniez plus du contrôle de source, vous feriez probablement mieux de l'écrire à partir de rien.

Rien ne prend moins de temps que pas de code.

Si vous devez plonger dans une base de code, vous avez besoin d'un peu de temps pour comprendre à quoi sert ce code et s'il ne sert à rien, vous avez besoin de plus de temps.

Ok - cela pourrait être guéri soit un commentaire, mais là encore, tout le monde va se demander pourquoi ce code inutilisé est toujours dans la base de code, qu'il soit supprimé ou non.

S'il n'y a rien, personne ne perdra du temps avec cela.

S'il était difficile de bien faire les choses, vous avez besoin d'une bonne documentation, du fait que ce code existe, mais si la base de code évolue au fil de certaines itérations, peut-être que cela ne fonctionnera plus, s'il est réactivé.

Supprimez le code inutilisé - moins d'encombrement, meilleure compréhension. Votre système de contrôle de version prendra soin de vous. De plus, si vous utilisez mieux que notepad, votre environnement vous permettra d'utiliser un code plus ancien pour référence.

Les longs commentaires de l'ancien code sont gênants et rendent la navigation difficile.

Cordialement

Suivez cet algorithme simple:

1. Est-il sauvegardé dans un SCM? Si oui, passez à 3.
2. Mettre en place un SCM.
3. Jeter les trucs .

Tous vos points en faveur de la suppression sont valables.

Tous vos arguments en faveur du maintien de l’encombrement ne sont plus valables une fois que vous avez un SCM pour le rechercher ou le restaurer. En fait, votre SCM devrait pouvoir vous aider à déterminer pourquoi ce code est là et n’est pas utilisé, s’il a été utilisé correctement.

Cela s'appelle "code mort" pour une raison. Laissez-le mourir et reposez en paix.

Il restera sous contrôle de source. il ne doit pas rester dans la base de code active.

La seule exception est que si le code termine la conception et que vous n'utilisez pas le code, vous prévoyez éventuellement de le rendre public et les autres utilisateurs souhaiteront peut-être cette fonctionnalité de base. Ensuite, concevez simplement des tests pour vous assurer que ces parties du code fonctionnent de manière à reproduire la manière dont vous proposez à d’autres personnes d’utiliser ces parties du code. Cependant, si vous envisagez même de supprimer le code et que vous ne pouvez pas trouver une raison valable pour le conserver, cela devrait disparaître. Le code inutilisé demande plus de travail à tout le monde (plus difficile à lire; le code peut être cassé; plus de travail à maintenir, etc.)

D'après mon expérience, supprimer le code inutilisé peut aussi se retourner contre nous. Vous pouvez oublier que vous aviez ce code et que vous ne le chercherez pas dans l'historique. Ou vous ne savez peut-être même pas que quelqu'un a implémenté ce code puis l'a supprimé ultérieurement. Encore une fois, vous ne le chercherez pas dans l'histoire ...

Sans doute, avoir du code inutilisé est une mauvaise odeur.

UPDATE: Je viens de remarquer que Ed Staub a donné une réponse très similaire.