.net - codeanalysis - code review tools visual studio 2017

¿Existe una regla FxCop personalizada que detecte los métodos PÚBLICOS no utilizados?

Question

Acabo de probar FxCop. Detecta métodos privados no utilizados, pero no públicos no utilizados. ¿Hay alguna regla personalizada que pueda descargar, un complemento que detecte métodos públicos que no se invocan desde el mismo ensamblado?

Answer 1

¿Cómo sabría que los métodos públicos no se usan?

Al marcar un método como público, puede acceder a él cualquier aplicación que haga referencia a su biblioteca.

Answer 2

Si un método no se utiliza y FxCop público asume que lo ha hecho público para que las cosas externas tengan acceso.

Si los métodos públicos no utilizados conducen a las advertencias de FxCop, escribir API y cosas por el estilo sería un problema: obtendría muchas advertencias de FxCop sobre los métodos que pretende que otros usen.

Si no necesita nada externo para acceder a su ensamblado / exe, considere buscar-reemplazar public con internal . Su aplicación se ejecutará igual y FxCop podrá encontrar los métodos internos sin referencia.

Si necesita acceso externo, encuentre qué métodos son realmente necesarios para ser externos y haga que todo lo demás sea interno.

Cualquier método que hagas visible externamente también podría tener pruebas unitarias.

Answer 3

NDepend es tu amigo para este tipo de cosas

Answer 4

Corey, mi respuesta al uso de FxCop asumió que estaba interesado en eliminar miembros privados no utilizados; sin embargo, para resolver el problema con otros casos puede intentar usar NDepend . Aquí hay algunos CQL para detectar miembros públicos no utilizados (adaptados de un artículo que se detalla a continuación):

// <Name>Potentially unused methods</Name>
WARN IF Count > 0 IN SELECT METHODS WHERE
 MethodCa == 0 AND            // Ca=0 -> No Afferent Coupling -> The method 
                              // is not used in the context of this
                              // application.

 IsPublic AND                 // Check for unused public methods

 !IsEntryPoint AND            // Main() method is not used by-design.

 !IsExplicitInterfaceImpl AND // The IL code never explicitely calls 
                              // explicit interface methods implementation.

 !IsClassConstructor AND      // The IL code never explicitely calls class
                              // constructors.

 !IsFinalizer                 // The IL code never explicitely calls
                              // finalizers.

Fuente: " Métricas de código sobre acoplamiento, código muerto, fallas de diseño y reingeniería" de Patrick Smacchia . El artículo también repasa la detección de campos y tipos muertos.

(EDITAR: la respuesta es más comprensible)

EDICIÓN 11 de junio de 2012: explique las nuevas instalaciones de NDepen con respecto al código no utilizado. Descargo de responsabilidad: soy uno de los desarrolladores de esta herramienta.

Desde que NDepend v4 se lanzó en mayo de 2012, la herramienta propone escribir Code Rule sobre LINQ Query (CQLinq) . Se proponen alrededor de 200 reglas de código predeterminadas , 3 de las cuales están dedicadas a la detección de código inactivo / no utilizado :

• Tipos potencialmente muertos (por lo tanto, detectar clase no utilizada, estructura, interfaz, delegar ...)
• Métodos potencialmente muertos (por lo tanto, detectar el método no utilizado, ctor, propiedad getter / setter ...)
• Campos potencialmente muertos

Estas reglas de código CQLinq son más potentes que las anteriores CQL. Si hace clic en estos 3 enlaces de arriba hacia el código fuente de estas reglas, verá que las relativas a los tipos y métodos son un poco complejas. Esto se debe a que detectan no solo los tipos y métodos no utilizados, sino también los tipos y métodos utilizados solo por métodos y tipos muertos no utilizados (recursivo).

Este es un análisis estático , de ahí el prefijo Potencialmente en los nombres de las reglas. Si un elemento de código se usa solo a través de la reflexión, estas reglas podrían considerarlo como no utilizado, que no es el caso.

Además de usar estas 3 reglas, recomendaría medir la cobertura del código mediante pruebas y esforzarse por tener una cobertura completa. A menudo, verá que el código que no puede ser cubierto por las pruebas, en realidad es código no utilizado / muerto que puede descartarse de manera segura. Esto es especialmente útil en algoritmos complejos donde no está claro si una rama de código es alcanzable o no.