Buscar código no utilizado [cerrado]


208

Tengo que refactorizar una aplicación C # grande, 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?




Me sorprende que esto esté etiquetado como fuera de tema, encontré que la pregunta y las respuestas son útiles 11 años después de que se escribió la pregunta. el enlace fuera de tema provisto dice que "... herramientas de software comúnmente utilizadas por los programadores; y es ..." es definitivamente relevante para SO !.
shelbypereira

Respuestas:


218

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


20
esto es genial. No hay suficiente gente que sepa sobre esto. También debe activar Solution Wide Analysis para que todo aparezca.
mcintyre321

16
Resharper es una gran herramienta, pero descubrí que no es confiable para esta tarea. Tengo un método público donde eliminé todas las referencias. Si hago clic derecho en el método y selecciono Mostrar usos, no hay ninguno, pero los problemas de código de Resharper no lo enumeran como no utilizado.
user890155

9
Estamos usando inyección de dependencia. Como resultado, todo parece acostumbrado a reorganizar porque incluso los tipos no utilizados todavía se registran con la unidad.
Montgomery 'monty' Jones

11
@ user890155 Eso sería porque el método es público, la biblioteca podría ser consumida por otra aplicación que no esté en la solución actual. Creo que solo marcará los métodos internos y privados como problemas de código si no se usan.
Lukazoid

3
@elggarc Con respecto a la inyección de dependencia, eche un vistazo al complemento del Agente Mulder mencionado aquí: blogs.jetbrains.com/dotnet/2012/08/resharper-70-plug-ins Página de inicio del proyecto: hmemcpy.github.com/AgentMulder Agent Mulder - soporte para Marcos de inyección de dependencias como Autofac, Castle Windsor, Unity. Dado que ReSharper no conoce estos contenedores, las clases pueden marcarse con frecuencia como no utilizadas o no instanciadas. El Agente Mulder le dice a ReSharper cuándo se están usando estas clases, y proporciona navegación al punto de registro desde cada clase.
Grzegorz Smulko

29

Es una gran pregunta, pero ten en cuenta que pisas aguas peligrosas aquí. Cuando elimine el código, deberá asegurarse de compilar y probar con frecuencia.

Una gran herramienta viene a la mente:

NDepend: esta herramienta es simplemente increíble. Se tarda un poco en asimilar, y después de los primeros 10 minutos creo que la mayoría de los desarrolladores solo dicen "¡A la mierda! y elimine la aplicación. Una vez que tenga una buena idea de NDepend, le brinda una visión increíble de cómo se acoplan sus aplicaciones. Compruébalo: http://www.ndepend.com/ . Lo más importante, 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 sea la herramienta que elija, no es una tarea tomar a la ligera. Especialmente si se trata de métodos públicos en ensamblajes de tipo de biblioteca, ya que es posible que nunca sepa cuándo una aplicación hace referencia a ellos.


44
Otra advertencia: si su aplicación es asp.net, con NDepend necesitará precompilar su sitio para que pueda analizar los códigos subyacentes y NDepend no puede cubrir / conocer las llamadas de las páginas aspx (es decir, llamadas a métodos en ObjectDataSources y el me gusta)
Jaime

16

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


15

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 una regla de código 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 no utilizado / muerto

Básicamente, una regla para detectar métodos no utilizados, por ejemplo, se ve así:

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

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

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

NDepend se integra en Visual Studio 2017,2015, 2013, 2012, 2010, por lo que estas reglas se pueden verificar / examinar / editar directamente dentro del IDE . La herramienta también se puede integrar 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 VS Team Services .

Si hace clic en estos 3 enlaces anteriores hacia el código fuente de estas reglas, verá que los que conciernen a los tipos y métodos son un poco complejos. 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 los tipos y métodos 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, lo 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 un 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 accesible o no.

Descargo de responsabilidad: trabajo para NDepend.


6

También mencionaría que usar COI, también conocido como Unity, puede hacer que estas evaluaciones sean engañosas. 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 hasta donde ReSharper puede decir. Si siguiera las recomendaciones de ReSharper, me mancharían.


4

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

En VS IDE, puede hacer clic con el botón derecho en la definición y elegir 'Buscar todas las referencias', aunque esto solo funciona en el nivel de solución.


1

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

Si cuenta con un conjunto completo de pruebas unitarias, puede utilizar la herramienta de cobertura de prueba para ver exactamente qué líneas de código no se ejecutaron durante la ejecución de la prueba. Aún deberá analizar el código manualmente: elimine lo que considera código muerto o escriba una prueba para mejorar la cobertura de la prueba.

Una de esas herramientas es NCover , con precursor de código abierto en Sourceforge . Otra alternativa es PartCover .

Mira esta respuesta en stackoverflow.


1

Me he encontrado con AXTools CODESMART ... Intenta eso 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.


0

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

Creo que NDepend parece un candidato más probable.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.