sharp - ¿Hay alguna herramienta para encontrar funciones sin referencias(código obsoleto muerto) en una aplicación C#?

estandar de documentacion de codigo c#

Question

Quiero eliminar foo () si no se llama a foo () desde ningún lugar.

Answer 1

Bueno, si VS no hace esto de forma nativa, un método simple es hacer clic derecho en el método y seleccionar "buscar todas las referencias". Si solo hay 1 referencia (donde se declara), lo más probable es que no se use en ningún otro lado.

Answer 2

Sí, el complemento MZ-Tools tiene una función de revisión del código inactivo.

Answer 3

NDepend también informará sobre el código potencialmente no utilizado.

Answer 4

Tenga en cuenta que Resharper (y probablemente otras herramientas similares también) no resaltará los métodos no utilizados si los métodos están marcados como public . No hay forma de que una herramienta de análisis de código estático pueda verificar si los métodos de su ensamblaje son utilizados por otros ensambles fuera de su solución. Por lo tanto, el primer paso para eliminar los métodos no utilizados es reducir su visibilidad a private o internal .

Answer 5

Resharper hace esto, y no solo con métodos. También lo hace con el uso de declaraciones, variables, etcétera.

Answer 6

La herramienta NDepend puede ayudar a encontrar el código no utilizado en una base de código .NET. Descargo de responsabilidad: soy uno de los desarrolladores de esta herramienta.

NDepend 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
• Campos potencialmente muertos

NDepend está integrado en Visual Studio, por lo tanto, estas reglas se pueden verificar / examinar / editar directamente dentro del IDE . La herramienta también puede integrarse en su proceso de CI y puede generar informes que mostrarán las reglas violadas y los elementos del código culpable.

Si hace clic en estos 3 enlaces 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 esforzarme 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.

Answer 7

Gendarme detectará métodos privados sin llamadores en sentido ascendente. Está disponible en plataforma cruzada, y la última versión maneja " AvoidUncalledPrivateCodeRule ".

FxCop detectará métodos públicos / protegidos sin llamadas en sentido ascendente. Sin embargo, FxCop no detecta todos los métodos sin llamadas ascendentes, ya que está destinado a verificar en el caso de que su código sea parte de una Biblioteca, por lo que los miembros públicos quedan excluidos. Puede usar NDepend para hacer una búsqueda de miembros públicos sin llamantes en sentido ascendente, que detallo aquí en esta otra respuesta de .

(editar: información adicional sobre Gendarme que en realidad hace lo que preguntó el interlocutor)