Suppression du code inutilisé dans Visual Studio

Question

En ce qui concerne cette question: " Supprimer les références inutilisées (! =" Using ") ", j'aimerais savoir s'il existe un outil permettant de supprimer les classes, structures, délégués, etc. inutilisés d'une solution Visual Studio.

Scénario:

J'ai une solution Visual Studio non organisée composée de 1 000 éléments:

• Importation de méthode native 
• Des structures 
• Les délégués
• Énumérations

Plutôt que de parcourir chaque fichier en cliquant sur "Rechercher toutes les références" et en déterminant si le code est utilisé quelque part, existe-t-il un mécanisme permettant de supprimer facilement les fichiers de code redondants?

Exemple:

//This class contains a method called getRandomValue which returns type RANDOM
public class NativeMethods
{
    [DllImport("random.dll")]
    public static extern RANDOM getRandomValue();
}

//This is the RANDOM object as referenced by getRandomValue();
[StructLayout(LayoutKind.Sequential)]
public struct RANDOM
{
    uint a;
    uint b;
    uint c;
}

//This is redundant since nothing is referencing it.
[StructLayout(LayoutKind.Sequential)]
public struct MESSAGE
{
    IntPtr sender;
    IntPtr recipient;
    char[] mText;
}

Note pour moi-même:

J’ai l’impression que cela va être délicat, car contrairement à Java, les noms d’objet ne doivent pas nécessairement être identiques au nom de fichier et plusieurs déclarations d’objet peuvent résider dans un seul fichier. déclarée dans son propre fichier (avec un nom identique).

Answer 1

ReSharper est le meilleur choix pour nettoyer votre code.

Vous pouvez l'utiliser gratuitement grâce à Programme ReSharper Early Access .

Answer 2

Il existe plusieurs outils que vous pouvez utiliser pour cela:

• FxCop (gratuit)
• NDepend (payé)
• Resharper (payé)

FxCop ne trouvera que le code interne et privé non utilisé. Bien sûr, si vous vous assurez que vous n'exposez publiquement que le code devant être accessible en dehors de votre Assemblée, vous devriez alors en profiter.

Answer 3

Comme indiqué @Ergwun, l'outil NDepend peut aider à trouver des méthodes, des champs et des types inutilisés. 

Pour plus de précision, NDepend propose d’écrire Code Rule over LINQ Query (CQLinq) . Environ 200 règles de code par défaut sont proposées, 3 d’entre elles étant dédiées à la détection de non utilisé/code mort

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

// <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 renverra des faux positifs triviaux. Il existe de nombreuses situations dans lesquelles une méthode n'est jamais appelée mais qu'elle n'est pas utilisée (point d'entrée, constructeur de classe, finaliseur, etc.), c'est pourquoi les 3 règles par défaut sont plus élaborées:

• Types potentiellement morts (détecte donc les classes, structures, interfaces, délégués, ... non utilisé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/éditées directement à l'intérieur de IDE . L'outil peut également être intégré dans votre processus de 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 les méthodes inutilisés, mais également les types et les méthodes utilisés uniquement par des types et des méthodes inutilisés (récursifs).

Il s'agit de static analysis, d'où le préfixe Potentially dans les noms de règles. Si un élément de code est utilisé uniquement 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 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 fait 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.

Disclaimer: Je travaille pour NDepend.