Trouver le code non utilisé

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 non utilisé afin de pouvoir supprimer toutes les fonctions inutilisées?

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

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

Un grand outil me vient à l’esprit:

NDepend – cet outil est tout simplement incroyable. Cela 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 “Vis!” et supprimez l’application. Une fois que vous avez une bonne idée de NDepend, cela vous donne un aperçu incroyable de la manière dont vos applications sont couplées. Check it out: http://www.ndepend.com/ . Plus important encore, cet outil vous permettra de visualiser les méthodes qui n’ont aucun appelant direct. Il vous montrera également l’inverse, un arbre d’appel complet pour toute méthode de l’assemblage (ou même entre les assemblages).

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

Resharper est bon pour cela, comme d’autres l’ont déclaré. Attention cependant, ces outils ne vous trouvent pas du code utilisé par reflection, par exemple ne peut pas savoir si du code n’est PAS utilisé par reflection.

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

Pour élaborer un peu, NDepend propose d’écrire une règle de code sur une requête LINQ (CQLinq) . Environ 200 règles de code par défaut sont proposées, dont trois dédiées à la détection des codes inutilisés / morts

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

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

Règle NDepend pour trouver des méthodes inutilisées (méthodes mortes)

Mais cette règle est naïve et renverra des faux positifs sortingviaux. Il y a beaucoup de situations où une méthode n’est jamais appelée mais 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:

  • Types potentiellement morts (détectent donc les classes, structures, interfaces, delegates inutilisés …)
  • Méthodes potentiellement mortes
  • Champs potentiellement morts

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 dans l’EDI . L’outil peut également être intégré à votre processus CI et il peut créer des rapports qui afficheront des règles violées et des é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 méthodes et les types morts inutilisés (récursifs).

C’est une parsing statique , d’où le préfixe Potentiellement dans les noms de règles. Si un élément de code n’est utilisé que par reflection, 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 conseillerais 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 réalité un 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 twig de code est accessible ou non.

Disclaimer: Je travaille pour NDepend.

Je voudrais également mentionner que l’utilisation d’IOC aka Unity peut induire en erreur ces évaluations. Je me suis peut-être trompé mais plusieurs classes très importantes instanciées via Unity semblent ne pas avoir d’instanciation pour autant que ReSharper puisse le dire. Si je suivais les recommandations ReSharper, je serais arrosé!

ReSharper fait un excellent travail de recherche de code inutilisé.

Dans l’IDE VS, vous pouvez faire un clic droit sur la définition et choisir “Rechercher toutes les références”, même si cela ne fonctionne qu’au niveau de la solution.

Je suis tombé sur AXTools CODESMART..Essayez cela une fois. Utilisez l’parsingur de code dans la section des avis. Il répertorie les fonctions locales et globales mortes ainsi que d’autres problèmes.

FXCop est un parsingur de code … Il fait beaucoup 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.

La vérité est que l’outil ne peut jamais vous donner une réponse certaine à 100%, mais l’outil de couverture peut vous donner un bon résultat.

Si vous utilisez une suite de tests unitaire 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 le test. Vous aurez toujours besoin d’parsingr le code manuellement: éliminez ce que vous considérez comme un code mort ou écrivez un test pour améliorer la couverture des tests.

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.