Existe-t-il un outil permettant de rechercher des fonctions non référencées (code mort, obsolète) dans une application C #? [fermé]

Question

Je veux supprimer foo () si foo () n'est appelé nulle part.

Answer 1

Gendarme détectera les méthodes privées sans appelant en amont. Il est disponible sur plusieurs plates-formes, et la dernière version gère & AvoidUncalledPrivateCodeRule " .

FxCop détectera les méthodes publiques / protégées sans appelant en amont. Cependant, FxCop ne détecte pas toutes les méthodes sans appelants en amont, car il est censé vérifier que votre code fait partie d'une bibliothèque et que les membres publics sont laissés de côté. Vous pouvez utiliser NDepend pour faire une recherche de membres publics sans appelant en amont, ce que je détaille ici dans cette autre réponse StackOverflow .

(edit: ajout d'informations sur le gendarme qui fait exactement ce que le questionneur a demandé)

Answer 2

NDepend rend également compte du code potentiellement inutilisé.

Answer 3

N'oubliez pas que Resharper (et probablement d'autres outils similaires également) ne mettra pas en évidence les méthodes inutilisées si elles sont marquées public . Il n’existe aucun moyen pour un outil d’analyse de code statique de vérifier si les méthodes de votre assembly sont utilisées par d’autres assemblys en dehors de votre solution. La première étape pour éliminer les méthodes inutilisées consiste à réduire leur visibilité à private ou internal .

Answer 4

Oui, le complément MZ-Tools dispose d'une fonctionnalité de révision du code mort.

Answer 5

Resharper le fait, et pas seulement avec des méthodes. Il le fait également en utilisant des instructions, des variables, etc.

Answer 6

L'outil NDepend peut aider à trouver du code inutilisé dans une base de code .NET. Avertissement: je suis l'un des développeurs de cet outil.

NDepend propose d'écrire Règle de code sur la requête LINQ (CQLinq) . Environ 200 règles de code par défaut sont proposées, 3 d'entre elles étant dédiées à non utilisées / détection de code mort :

• Types potentiellement morts (détectez donc les classes, structures et interfaces inutilisées , délégué ...)
• Méthodes potentiellement mortes
• Champs potentiellement morts

NDepend étant intégré à Visual Studio, ces règles peuvent donc être vérifiées / parcourues / modifiées à l'intérieur de l'EDI . Cet outil peut également être intégré à votre processus de CI et créer des rapports indiquant que les règles ont été violées et éléments de code coupables.

Si vous cliquez sur ces 3 liens 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 les méthodes inutilisés non utilisés (récursifs).

Il s'agit de l'analyse statique , d'où le préfixe Potentiellement dans les noms de règles. Si un élément de code est utilisé uniquement par réflexion, ces règles pourraient 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 de code par des tests et d’essayer d’obtenir une couverture complète. Vous verrez souvent que le code qui ne peut pas être couvert par des tests est en réalité un code non utilisé / 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.

Answer 7

Eh bien, si VS ne le fait pas de manière native, une méthode simple consiste à cliquer avec le bouton droit de la souris sur la méthode et à sélectionner "Rechercher toutes les références". . S'il n'y a qu'une seule référence (où elle est déclarée), elle ne sera probablement utilisée nulle part ailleurs.