Trouver le code non utilisé [fermé]
je dois remanier un grand C# application, et j'ai trouvé beaucoup de fonctions qui ne sont jamais utilisées. Comment puis-je vérifier le code non utilisé, pour que je puisse supprimer toutes les fonctions non utilisées?
9 réponses
Oui, ReSharper fait ça. Cliquez avec le bouton droit de la souris sur votre solution et sélectionnez "find Code Issues". L'un des résultats est "symboles inutilisés". Cela vous montrera les classes, les méthodes, etc. qui ne sont pas utilisés.
c'est une grande question, mais soyez avertis que vous marchez dans des eaux dangereuses ici. Lorsque vous supprimez du code, vous devez vous assurer de compiler et de tester souvent.
un grand outil venu à l'esprit:
NDepend - cet outil est tout simplement incroyable. Ça prend un peu de temps pour grok, et après les 10 premières minutes je pense que la plupart des développeurs disent juste "au diable!"et supprimer l'application. Une fois que vous avez une bonne sensation pour NDepend, il vous donne incroyable aperçu de la façon dont vos applications sont couplés. Regarde: http://www.ndepend.com / . Plus important encore, cet outil vous permettra de voir des méthodes qui n'ont pas d'appelants directs. Il sera également vous montrer l'inverse, un arbre d'appel pour n'importe quelle méthode de l'assemblée (ou même entre les assemblées).
quel que soit l'outil que vous choisissez, ce n'est pas une tâche à prendre à la légère. En particulier si vous avez affaire à des méthodes publiques sur des Assemblées de type bibliothèque, comme vous pouvez on ne sait jamais quand une application les renvoie.
Resharper est bon pour cela comme d'autres l'ont déclaré. Attention cependant, ces outils ne vous trouvent pas de code qui est utilisé par réflexion, par exemple ne peut pas savoir si un code n'est pas utilisé par réflexion.
comme L'a souligné Jeff l'outil NDepend peut aider à trouver les méthodes, les champs et les types inutilisés.
pour développer un bit, NDepend propose d'écrire règle de Code sur LINQ Query (CQLinq) . Autour de 200 règles de code par défaut sont proposés, 3 d'entre eux étant dédié à code non utilisé /mort détection
essentiellement une telle règle pour détecter la méthode non utilisée par exemple on dirait:
// <Name>Dead Methods</Name>
warnif count > 0
from m in Application.Methods where !m.MethodsCallingMe.Any()
select m
mais cette règle est naïve et retournera des faux positifs insignifiants. Il existe de nombreuses situations où une méthode n'est jamais appelée mais n'est pas inutilisée (point d'entrée, constructeur de classe, finaliseur...) c'est pourquoi les 3 règles par défaut sont plus élaborée:
- Potentially dead Types (donc détecter la classe non utilisée), Structure, interface, délégué...)
- Potentiellement morts Méthodes
- Potentiellement morts Champs
NDepend intègre dans Visual Studio 20172015, 2013, 2012, 2010, ces règles peuvent donc être cochée/parcourue/éditée directement à l'intérieur de l'IDE . L'outil peut également être intégré dans votre processus de CI et il peut construire rapports cela montrera les règles violées et les éléments de code coupable. NDepend a également un VS Team Services extension .
si vous cliquez sur ces 3 liens ci-dessus vers le code source de ces règles, vous verrez que celles concernant les types et les méthodes sont un peu complexes. En effet, ils détectent non seulement les types et méthodes inutilisés, mais aussi les types et méthodes utilisés seulement par les types et méthodes morts inutilisés (récursifs).
C'est analyse statique , d'où le préfixe potentiellement dans les noms de règles. Si un élément de code est utilisé seulement par réflexion, ces règles pourraient le considérer comme non utilisé, ce qui n'est pas le cas.
en plus d'utiliser ces 3 règles, je conseillerais de mesurer la couverture du code par des tests et de s'efforcer d'avoir une couverture complète. Souvent, vous verrez que le code qui ne peut pas être couvert par des tests, est en fait unused/dead code qui peut être jeté en toute sécurité. Ceci est particulièrement utile dans des algorithmes complexes où il n'est pas clair si une branche de code est accessible ou pas.
clause de non-responsabilité: je travaille pour NDepend.
je voudrais également mentionner que l'utilisation de L'Unité AKA du CIO peut rendre ces évaluations trompeuses. J'ai peut-être commis une erreur, mais plusieurs classes très importantes qui sont instanciées via L'unité ne semblent pas avoir d'instanciation aussi loin que ReSharper peut le dire. Si je suivais les recommandations de ReSharper, je me ferais droguer!
ReSharper fait un excellent travail de trouver le code inutilisé.
dans le VS IDE, vous pouvez faire un clic droit sur la définition et choisir ' Find All Références", bien que cela ne fonctionne qu'au niveau de la solution.
j'ai rencontré AXTools CODESMART..Essaie ça une fois. Utilisez l'analyseur de code dans la section commentaires.Il listera les fonctions locales et globales mortes avec d'autres questions.
La vérité est que l'outil ne peut jamais vous donner 100% de réponse certaine, mais la couverture de l'outil peut vous donner une assez bonne course pour l'argent.
si vous comptez avec la suite de test d'unité complète, que vous pouvez utiliser l'outil de couverture de test pour voir exactement quelles lignes de code n'ont pas été exécutées pendant l'exécution du test. Vous aurez toujours besoin d'analyser le code manuellement: soit éliminer ce que vous considérez comme du code mort ou écrire un test pour améliorer la couverture du test.
One cet outil est NCover , avec un précurseur open source sur Sourceforge . Une autre alternative est PartCover .
vérifiez ce répondez sur stackoverflow.