Encuentra el código no utilizado

Tengo que refactorizar una gran aplicación C #, y encontré muchas funciones que nunca se usan. ¿Cómo puedo verificar el código no utilizado para poder eliminar todas las funciones no utilizadas?

Sí, ReSharper hace esto. Haga clic derecho en su solución y selección “Buscar problemas de código”. Uno de los resultados es “Símbolos no utilizados”. Esto le mostrará clases, métodos, etc., que no se usan.

Es una gran pregunta, pero ten en cuenta que estás pisando aguas peligrosas aquí. Cuando elimine el código, deberá asegurarse de estar comstackndo y probando a menudo.

Una gran herramienta viene a la mente:

NDepende: esta herramienta es simplemente increíble. Me lleva un poco de tiempo asimilar, y después de los primeros 10 minutos, creo que la mayoría de los desarrolladores solo dicen “¡A la mierda!” y eliminar la aplicación. Una vez que tenga una buena idea de NDepend, le dará una visión increíble de cómo se acoplan sus aplicaciones. Compruébelo: http://www.ndepend.com/ . Lo más importante es que esta herramienta le permitirá ver métodos que no tienen llamadas directas. También le mostrará el inverso, un árbol de llamadas completo para cualquier método en el ensamblaje (o incluso entre ensamblajes).

Cualquiera que sea la herramienta que elija, no es una tarea a tomar a la ligera. Especialmente si se trata de métodos públicos en conjuntos de tipo de biblioteca, ya que nunca se sabe cuando una aplicación los está haciendo referencia.

Resharper es bueno para esto, como otros han declarado. Sin embargo, tenga cuidado, estas herramientas no encuentran el código que utiliza la reflexión, por ejemplo, no pueden saber si el código NO se usa por reflexión.

Como señaló Jeff, la herramienta NDepend puede ayudar a encontrar métodos, campos y tipos no utilizados.

Para elaborar un poco, NDepend propone escribir Code Rule sobre LINQ Query (CQLinq) . Se proponen alrededor de 200 reglas de código predeterminadas , 3 de ellas dedicadas a la detección de código inactivo / no utilizado

Básicamente, tal regla para detectar el método no utilizado, por ejemplo, se ve así:

// Dead Methods warnif count > 0 from m in Application.Methods where !m.MethodsCallingMe.Any() select m 

NDepende la regla para encontrar métodos no utilizados (métodos muertos)

Pero esta regla es ingenua y devolverá falsos positivos triviales. Hay muchas situaciones en las que nunca se llama un método pero no se utiliza (punto de entrada, constructor de clase, finalizador …) por eso las 3 reglas predeterminadas son más elaboradas:

  • Tipos potencialmente muertos (por lo tanto, detectar clase no utilizada, estructura, interfaz, delegar …)
  • Métodos potencialmente muertos
  • Campos potencialmente muertos

NDepend se integra en Visual Studio 2017,2015, 2013, 2012, 2010, 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. NDepend también tiene una extensión de VS Team Services .

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 twig de código es alcanzable o no.

Descargo de responsabilidad: trabajo para NDepend.

También mencionaría que usar COI también conocido como Unity puede hacer que estas evaluaciones sean confusas. Es posible que haya cometido un error, pero varias clases muy importantes que se instancian a través de Unity parecen no tener instanciación por lo que ReSharper puede decir. ¡Si siguiera las recomendaciones de ReSharper me mancharían con una manguera!

ReSharper hace un gran trabajo al encontrar el código no utilizado.

En VS IDE, puede hacer clic derecho en la definición y seleccionar ‘Buscar todas las referencias’, aunque esto solo funciona en el nivel de solución.

Me he encontrado con AXTools CODESMART … Pruébalo una vez. Use el analizador de código en la sección de revisiones. Enumerará las funciones locales y globales muertas junto con otros problemas.

FXCop es un analizador de código … Hace mucho más que encontrar el código no utilizado. Utilicé FXCop por un tiempo, y estaba tan perdido en sus recomendaciones que lo desinstalé.

Creo que NDepend parece ser un candidato más probable.

La verdad es que la herramienta nunca puede darle una respuesta 100% segura, pero la herramienta de cobertura puede darle una buena corrida por el dinero.

Si cuenta con un conjunto completo de pruebas de unidad, entonces puede usar la herramienta de cobertura de prueba para ver exactamente qué líneas de código no se ejecutaron durante la prueba. Todavía tendrá que analizar el código manualmente: elimine lo que considera un código muerto o realice una prueba de escritura para mejorar la cobertura de la prueba.

Una de esas herramientas es NCover , con un precursor de fuente abierta en Sourceforge . Otra alternativa es PartCover .

Mira esta respuesta en stackoverflow.