¿Cuáles son algunas de las estrategias que se utilizan al implementar el análisis FxCop/static en bases de códigos existentes con violaciones existentes? ¿Cómo puede uno reducir de manera más efectiva las violaciones del análisis estático?¿Cómo se implementa un análisis FxCop/static en una base de código existente
Para empezar, haga un uso liberal del atributo [SuppressMessage]. Al menos al principio. Una vez que obtiene el recuento a 0 a través del atributo, a continuación, establece una regla que los nuevos checkins no pueden introducir violaciones FxCop.
Visual Studio 2008 tiene una buena característica de análisis de código que le permite garantizar que el análisis de código se ejecuta en cada compilación y puede tratar las advertencias como errores. Eso puede ralentizar un poco las cosas, así que recomiendo configurar un servidor de integración continua (como CruiseControl.NET) y hacer que se ejecute el análisis del código cada vez que se registre.
Una vez que lo tenga bajo control y no presente nuevas infracciones con cada checkin, comience a atacar clases enteras de violaciones de FxCop a la vez con el objetivo de eliminar los SuppressMessageAttributes que utilizó.
La manera de hacer un seguimiento de cuáles realmente desea conservar es agregar siempre un valor de Justificación a los que realmente desea suprimir.
¡Reescriba su código en un estilo que pase!
En serio, una base de código antigua tendrá cientos de errores, pero es por eso que tenemos programadores novatos/pasantes. Corregir las infracciones de FxCop es una excelente forma de obtener una descripción general de la base de código y también aprender a escribir el código .NET conforme.
Así que, solo muerde la bala, bebe mucha cafeína, ¡y solo hazlo en un par de días!
NDepende looks like podría hacer lo que está buscando, pero no estoy seguro de si puede integrarse en una compilación automatizada de CruiseControl.Net, y fallar la construcción si el código no cumple con los requisitos (que es lo que me gustaría que sucediera).
¿Alguna otra idea?
Una alternativa a FxCop sería utilizar la herramienta NDepend. Esta herramienta permite escribir Reglas de código sobre C# LINQ consultas (lo que llamamos CQLinq). Descargo de responsabilidad: soy uno de los desarrolladores de la herramienta
Más de 200 code rules se han propuesto por defecto. La personalización de las reglas existentes o la creación de sus propias reglas es sencilla gracias a la conocida sintaxis C# LINQ.
Para mantener el número de falsos positivos baja, CQLinq ofrece las capacidades únicas para definir lo que es el conjunto JustMyCode través de consultas especiales de código con el prefijo notmycode. Se pueden encontrar más explicaciones acerca de esta característica here.Éstos son por ejemplo dos notmycode consultas predeterminadas:
Para mantener el número de falsos positivos baja, con CQLinq también se puede enfocar reglas resultan sólo en código añadido o código refactorizado, desde un defined baseline in the past. Ver la siguiente regla, que detectan los métodos añadidos o refactorizado demasiado compleja desde la línea de base:
warnif count > 0
from m in Methods
where m.CyclomaticComplexity > 20 &&
m.WasAdded() || m.CodeWasChanged()
select new { m, m.CyclomaticComplexity }
Por último, el aviso de que con las reglas del código NDepend se pueden verificar live in Visual Studio y en tiempo de proceso de construcción, en un generated HTML+javascript report.