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?Buscar el código no utilizado
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.
esto es genial. no hay suficiente gente sabe sobre esto. También debe activar Solution Wide Analysis para que todo se muestre. – mcintyre321
Resharper es una gran herramienta, pero me pareció poco confiable para esta tarea. Tengo un método público donde eliminé todas las referencias. Si hago clic con el botón derecho en el método y selecciono Mostrar usos, no aparece ninguno, pero los problemas del código de Resharper no aparecen como no utilizados. – user890155
En la respuesta de Jarrett Meyer, haga clic derecho en "proyecto" en lugar de "solución" para guardar el tiempo de búsqueda en una solución multiproyecto. – fab
ReSharper hace un buen trabajo al encontrar el código no utilizado.
En el VS IDE, puede hacer clic derecho en la definición y seleccionar 'Encontrar todas las referencias ', aunque esto solo funciona en el nivel de solución.
Es una gran pregunta, pero se advirtió que estás pisando aguas peligrosas aquí. Cuando elimine el código, deberá asegurarse de estar compilando y probando a menudo.
Una gran herramienta vienen a la mente:
NDepend - 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. Verifíquelo: 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.
Otra palabra de advertencia, si su aplicación es asp.net, con NDepende usted necesita precompilar su sitio para poder 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 similares) – Jaime
Resharper es bueno para esto, como han dicho otros. Sin embargo, ten cuidado, estas herramientas no encuentran tu código que se usa por reflexión, p. Ej. no puedo saber si el código NO es usado por reflexión.
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 estas herramientas es NCover, con el precursor de código abierto en Sourceforge. Otra alternativa es PartCover.
Echa un vistazo a este answer en stackoverflow.
Como señaló Jeff, la herramienta NDepend puede ayudarlo a encontrar métodos, campos y tipos no utilizados.
Para elaborar un poco, NDepend 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
Básicamente tal regla para detectar método no utilizado, por ejemplo, se parece a:
// <Name>Dead Methods</Name>
warnif count > 0
from m in Application.Methods where !m.MethodsCallingMe.Any()
select m
Pero esta regla es ingenuo y devolverá falsos positivos triviales. Hay muchas situaciones en las que un método nunca es llamado, sin embargo, no es utilizado (punto de entrada, constructor de la clase, finaliser ...) es por eso que las reglas predeterminadas 3 son más elaborados:
NDepend integra en Visual Studio 2017,2015, 2013, 2012, 2010, por lo que estas reglas pueden ser checked/browsed/edited right inside the IDE. La herramienta también se puede integrar en su proceso de CI y puede compilar reports que mostrará las reglas violadas y los elementos del código culpable. NDepend también tiene un VS Team Services extension.
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.
Descargo de responsabilidad: Trabajo para NDepend.
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.
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!
posible duplicado de [¿Qué herramientas y técnicas utiliza para encontrar el código muerto en .NET?] (Http://stackoverflow.com/questions/162641/what-tools-and-techniques-do-you-use- to-find-dead-code-in-net) –
posible duplicado de [¿Hay una herramienta para encontrar funciones sin referencias (código obsoleto, muerto) en una aplicación C#?] (http: // stackoverflow.com/questions/65585/is-there-a-tool-for-finding-unreferenced-functions-dead-obsolete-code-in-ac) – nawfal