¿Existe una regla FxCop personalizada que detectará los métodos PUBLICOS 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

NDepend es su amigo para este tipo de cosas

Answer 2

¿Cómo se sabe que los métodos públicos no se utilizan?

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

Answer 3

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: recibiría un montón de advertencias de FxCop sobre los métodos que pretende que otros utilicen.

Si no necesita nada externo para acceder a su ensamblado/exe, busque find-shining 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 todo el resto interno.

Cualquier método que haga visible externamente podría tener también pruebas de unidad.

Answer 4

Corey, mi respuesta al uso de FxCop asumió que usted estaba interesado en eliminar miembros privados no utilizados; sin embargo, para resolver el problema con otros casos, puede intentar usar NDepend. Aquí hay alguna CQL para detectar miembros públicos no utilizados (adaptado de un artículo que aparece 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: Patrick Smacchia's "Code metrics on Coupling, Dead Code, Design flaws and Re-engineering. El artículo también repasa la detección de campos y tipos muertos.

(EDIT: Respondió más comprensible)

---

EDITAR 11ª Junio ​​2012: Explicar nuevas instalaciones NDepend relativos código no utilizado. Descargo de responsabilidad: soy uno de los desarrolladores de esta herramienta.

Desde que se publicó NDepend v4 en mayo de 2012, la herramienta propone escribir Code Rule over LINQ Query (CQLinq). Alrededor se proponen 200 default code rules, 3 de ellos está dedicado a código no utilizado/muertos detección:

• Potentially dead Types (de ahí detectar clase no utilizada, estructura, interfaz, delegar ...)
• Potentially dead Methods (por lo tanto, detectar método sin usar, Héctor, propiedad de captador/definidor ...)
• Potentially dead Fields

Estas reglas del código de CQLinq son más pow erful que los 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 no solo detectan los tipos y métodos no utilizados, sino también los tipos y métodos utilizados solo por tipos y métodos muertos no utilizados (recursivo).

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

Además de utilizar estas 3 reglas, aconsejaría medir la cobertura del código mediante pruebas y esforzarse por tener una cobertura total. A menudo, verá que el código que no puede ser cubierto por las pruebas es en realidad 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.