¿Cómo se implementa FxCop/análisis estático en una base de código existente?

Question

¿Cuáles son algunas de las estrategias que se utilizan al implementar FxCop/análisis estático en bases de código existentes con violaciones existentes?¿Cómo se pueden reducir más eficazmente las violaciones del análisis estático?

Answer 1

Para empezar, haga un uso liberal del atributo [SuppressMessage].Al menos al principio.Una vez que obtiene el conteo a 0 a través del atributo, establece una regla que indica que los nuevos registros no pueden introducir violaciones de FxCop.

Visual Studio 2008 tiene una característica interesante de análisis de código que le permite asegurarse de que el análisis de código se ejecute en cada compilación y puede tratar las advertencias como errores.Eso podría ralentizar un poco las cosas, por lo que recomiendo configurar un servidor de integración continua (como CruiseControl.NET) y ejecutar un análisis de código en cada registro.

Una vez que lo tenga bajo control y no introduzca nuevas infracciones con cada registro, comience a abordar clases enteras de infracciones de FxCop a la vez con el objetivo de eliminar los SuppressMessageAttributes que utilizó.

La forma de realizar un seguimiento de cuáles realmente desea conservar es agregar siempre un valor de Justificación a los que realmente desea suprimir.

Answer 2

¡Reescribe tu código en un estilo pasajero!

En serio, una base de código antigua tendrá cientos de errores, pero es por eso que tenemos programadores novatos/internos.Corregir las violaciones de FxCop es una excelente manera de obtener una descripción general del código base y también aprender a escribir código .NET conforme.

¡Así que haz el esfuerzo, bebe mucha cafeína y resuélvelo en un par de días!

Answer 3

NDepende parece podría hacer lo que busca, pero no estoy seguro de si se puede integrar en una compilación automatizada de CruiseControl.Net y fallar en la compilación si el código no cumple con los requisitos (que es lo que me gustaría suceder).

¿Alguna otra idea?

Answer 4

Una alternativa a FxCop sería utilizar la herramienta. NDepende.Esta herramienta permite escribir Reglas de código sobre consultas LINQ de C# (lo que llamamos CQLinq). Descargo de responsabilidad:Soy uno de los desarrolladores de la herramienta.

Más que 200 reglas de código se proponen por defecto.Personalizar reglas existentes o crear tus propias reglas es sencillo gracias a la bien conocido Sintaxis de C#LINQ.

Para mantener baja la cantidad de falsos positivos, CQLinq ofrece capacidades únicas para definir cuál es el conjunto Sólo mi código a través de consultas de códigos especiales con el prefijo notmycode.Se pueden encontrar más explicaciones sobre esta característica. aquí.Aquí hay por ejemplo dos notmycode consultas predeterminadas:

• Descartar los métodos generados y de diseñador de JustMyCode
• Descartar los tipos generados desde JustMyCode

Para mantener baja la cantidad de falsos positivos, con CQLinq también puede enfocar el resultado de las reglas solo en el código agregado o refactorizado, ya que un línea de base definida en el pasado.Consulte la siguiente regla, que detecta métodos demasiado complejos agregados o refactorizados desde la línea base:

warnif count > 0 
from m in Methods
where m.CyclomaticComplexity > 20 &&
      m.WasAdded() || m.CodeWasChanged()
select new { m, m.CyclomaticComplexity }

Finalmente, observe que con el código NDepend se pueden verificar las reglas. vivir en Visual Studio y en el momento del proceso de construcción, en un informe HTML+javascript generado.