Trouver le code inutilisé [fermé]


208

Je dois refactoriser une grande application C #, et j'ai trouvé beaucoup de fonctions qui ne sont jamais utilisées. Comment puis-je vérifier le code inutilisé, afin de pouvoir supprimer toutes les fonctions inutilisées?



1
doublon possible de Y a
nawfal

Je suis surpris que cela soit étiqueté comme hors sujet, j'ai trouvé la question et les réponses utiles 11 ans après la rédaction de la question. le lien hors sujet fourni indique que "... les outils logiciels couramment utilisés par les programmeurs; et est ..." est certainement pertinent pour SO !.
shelbypereira

Réponses:


218

Oui, ReSharper fait cela. Faites un clic droit sur votre solution et sélectionnez "Rechercher les problèmes de code". L'un des résultats est "Symboles inutilisés". Cela vous montrera les classes, méthodes, etc., qui ne sont pas utilisées.


20
c'est bien. pas assez de gens le savent. Vous devez également activer l'analyse à l'échelle de la solution pour que tout s'affiche.
mcintyre321

16
Resharper est un excellent outil, mais je l'ai trouvé peu fiable pour cette tâche. J'ai une méthode publique où j'ai supprimé toutes les références. Si je clique avec le bouton droit sur la méthode et sélectionne Afficher les utilisations, il n'y en a pas, mais les problèmes de code de Resharper ne le répertorient pas comme inutilisé.
user890155

9
Nous utilisons l'injection de dépendance. Par conséquent, tout semble utilisé pour être réaffiché car même les types inutilisés sont toujours enregistrés avec l'unité.
Montgomery 'monty' Jones

11
@ user890155 Ce serait parce que la méthode est publique, la bibliothèque pourrait être consommée par une autre application qui n'est pas dans la solution actuelle. Je crois qu'il ne signalera les méthodes internes et privées comme étant des problèmes de code que si elles ne sont pas utilisées.
Lukazoid

3
@elggarc Concernant l'injection de dépendances, jetez un œil au plugin Agent Mulder mentionné ici: blogs.jetbrains.com/dotnet/2012/08/resharper-70-plug-ins Page d'accueil du projet: hmemcpy.github.com/AgentMulder Agent Mulder - support pour Cadres d'injection de dépendance tels que Autofac, Castle Windsor, Unity. Étant donné que ReSharper ne connaît pas ces conteneurs, les classes peuvent souvent être marquées comme inutilisées ou non instanciées. L'agent Mulder indique à ReSharper quand ces classes sont utilisées et fournit une navigation vers le point d'enregistrement à partir de chaque classe.
Grzegorz Smulko

29

C'est une excellente question, mais sachez que vous marchez dans des eaux dangereuses ici. Lorsque vous supprimez du code, vous devrez vous assurer que vous compilez et testez souvent.

Un excellent outil me vient à l'esprit:

NDepend - cet outil est tout simplement incroyable. Il faut un peu de temps pour grogner, et après les 10 premières minutes, je pense que la plupart des développeurs disent simplement "Vissez-le!" et supprimez l'application. Une fois que vous avez une bonne idée de NDepend, cela vous donne un aperçu incroyable de la façon dont vos applications sont couplées. Découvrez-le: http://www.ndepend.com/ . Plus important encore, cet outil vous permettra de visualiser les méthodes qui n'ont pas d'appel direct. Il vous montrera également l'inverse, une arborescence d'appels complète pour n'importe quelle méthode dans l'assembly (ou même entre les assemblys).

Quel que soit l'outil que vous choisissez, ce n'est pas une tâche à prendre à la légère. Surtout si vous avez affaire à des méthodes publiques sur des assemblys de type bibliothèque, car vous ne saurez peut-être jamais quand une application les référence.


4
Une autre mise en garde, si votre application est asp.net, avec NDepend vous devrez précompiler votre site afin que vous puissiez analyser les codes-behinds et NDepend ne peut pas couvrir / connaître les appels des pages aspx (c'est-à-dire les appels de méthode dans ObjectDataSources et le comme)
Jaime

16

Resharper est bon pour cela, comme d'autres l'ont dit. Attention cependant, ces outils ne trouvent pas le code utilisé par la réflexion, par exemple, ne peuvent pas savoir si un certain code n'est PAS utilisé par la réflexion.


15

Comme l'a souligné Jeff, l'outil NDepend peut aider à trouver des méthodes, des champs et des types inutilisés.

Pour élaborer un peu, NDepend propose d'écrire la règle de code sur LINQ Query (CQLinq) . Environ 200 règles de code par défaut sont proposées, dont 3 dédiées à la détection de code inutilisé / mort

Fondamentalement, une telle règle pour détecter une méthode inutilisée ressemble par exemple à:

// <Name>Dead Methods</Name>
warnif count > 0 
from m in Application.Methods where !m.MethodsCallingMe.Any()
select m

Règle NDepend pour rechercher les méthodes inutilisées (méthodes mortes)

Mais cette règle est naïve et renvoie des faux positifs triviaux. Il existe de nombreuses situations où une méthode n'est jamais appelée mais n'est pas utilisée (point d'entrée, constructeur de classe, finaliseur ...) c'est pourquoi les 3 règles par défaut sont plus élaborées:

NDepend s'intègre dans Visual Studio 2017,2015, 2013, 2012, 2010, ainsi ces règles peuvent être vérifiées / parcourues / modifiées directement à l'intérieur de l'IDE . L'outil peut également être intégré à votre processus CI et il peut créer des rapports qui montreront les règles violées et les éléments de code coupables. NDepend a également une extension VS Team Services .

Si vous cliquez sur ces 3 liens ci-dessus vers le code source de ces règles, vous verrez que ceux 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 également les types et méthodes utilisés uniquement par les types et méthodes morts inutilisés (récursifs).

Il s'agit d' une analyse statique , d'où le préfixe Potentiellement dans les noms de règles. Si un élément de code n'est utilisé que par réflexion, ces règles peuvent le considérer comme inutilisé, ce qui n'est pas le cas.

En plus d'utiliser ces 3 règles, je vous conseille de mesurer la couverture du code par des tests et de vous 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 du code inutilisé / mort qui peut être supprimé en toute sécurité. Ceci est particulièrement utile dans les algorithmes complexes où il n'est pas clair si une branche de code est accessible ou non.

Avertissement: je travaille pour NDepend.


6

Je voudrais également mentionner que l'utilisation d'IOC aka Unity peut rendre ces évaluations trompeuses. Je me suis peut-être trompé mais plusieurs classes très importantes qui sont instanciées via Unity semblent n'avoir aucune instanciation pour autant que ReSharper puisse le dire. Si je suivais les recommandations de ReSharper, je me ferais arroser!


4

ReSharper fait un excellent travail pour trouver le code inutilisé.

Dans VS IDE, vous pouvez cliquer avec le bouton droit sur la définition et choisir «Rechercher toutes les références», bien que cela ne fonctionne qu'au niveau de la solution.


1

La vérité est que l'outil ne peut jamais vous donner une réponse sûre à 100%, mais l'outil de couverture peut vous donner une assez bonne course pour l'argent.

Si vous comptez avec une suite de tests unitaires complète, 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 devrez toujours analyser le code manuellement: soit éliminer ce que vous considérez comme du code mort, soit écrire un test pour améliorer la couverture du test.

Un de ces outils est NCover , avec un précurseur open source sur Sourceforge . Une autre alternative est PartCover .

Découvrez cette réponse sur stackoverflow.


1

J'ai rencontré AXTools CODESMART..Essayez une fois. Utilisez l'analyseur de code dans la section des revues. Il listera les fonctions locales et globales mortes ainsi que d'autres problèmes.


0

FXCop est un analyseur de code ... Il fait bien plus que trouver du code inutilisé. J'ai utilisé FXCop pendant un certain temps et j'étais tellement perdu dans ses recommandations que je l'ai désinstallé.

Je pense que NDepend ressemble à un candidat plus probable.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.