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

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 rechercher des membres du public 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 ce que le questionneur a demandé)

NDepend fera également un rapport sur le code potentiellement inutilisé.

N’oubliez pas que Resharper (et probablement aussi d’autres outils similaires) ne mettra pas en évidence les méthodes inutilisées si les méthodes sont marquées comme public . Il n’existe aucun moyen pour un outil d’parsing 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 dans l’élimination des méthodes inutilisées consiste donc à réduire leur visibilité, qu’elle soit private ou internal .

Oui, le complément MZ-Tools possède une fonctionnalité de révision du code mort.

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

L’outil NDepend peut vous 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 une règle de code sur une requête LINQ (CQLinq) . Environ 200 règles de code par défaut sont proposées, dont 3 sont dédiées à la détection de code inutilisé / mort :

• Types potentiellement morts (détectent donc la classe, la structure, l’interface, le délégué … non utilisés)
• Méthodes potentiellement mortes
• Champs potentiellement morts

NDepend étant intégré à Visual Studio, ces règles peuvent donc être vérifiées / consultées / modifiées directement dans l’EDI . L’outil peut également être intégré à votre processus de CI et vous permettre de générer des rapports montrant les règles violées et les éléments de code incriminés.

Si vous cliquez sur ces 3 liens 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 é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 parsing statique , d’où le préfixe Potential dans les noms de règles. Si un élément de code est utilisé uniquement 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 de 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.

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.