Cómo administrar los abrumadores informes FxCop

Question

Recientemente comencé a usarlo. Sin embargo, después de ejecutarlo contra uno de los proyectos más grandes de mi empresa. Resulta montañas de problemas.

La lista de problemas era tan abrumadora que tomaría días encontrar y corregir algunas, si no todas las cosas.

Ahora, sé que no es muy práctico arreglar todo lo que FxCop le dice que solucione. Pero como soy nuevo en esta pequeña herramienta ...

¿Cuáles son algunos buenos consejos y trucos sobre el uso de FxCop de manera efectiva?

¿En un proyecto nuevo y en un proyecto existente?

Si también se proporciona a los programadores en mi empresa generalmente escribe un buen código?

Answer 1

Al principio puede comenzar con un pequeño conjunto de reglas al principio. Y luego aumente la cantidad de reglas que aplica.

Y también hay que echar un vistazo a las respuestas this questio de n ...

Answer 2

Cree una línea base ejecutando fxCop una vez y excluyendo todo lo que encuentre.

Guárdelo como un archivo .fxcop y úselo para ejecutar comprobaciones futuras.

Luego, cuando realice cambios en su código, creará nuevas y manejables violaciones. FxCop cambiará las cosas si cambias la firma de un método, por ejemplo.

Si tiene tiempo, puede abordar una categoría de infracciones de a una por vez, sin anularlas.

Answer 3

ordenar la salida por el tipo de regla ... y luego ir a través de la lista de clasificación para ver qué subconjunto de los tipos de reglas rotas son importantes y vale la pena arreglar IYO.

Answer 4

No todo lo que informa fxCop es un problema de "obligación imperceptible". Por ejemplo, insertar la entrada del usuario en un comando de la base de datos utilizando la concatenación de cadenas es mucho peor que los problemas de estilo como el húngaro o la captura de excepciones en lugar de una excepción más específica.

Answer 5

Definitivamente filtra las que no son importantes para tu organización. Por ejemplo, todo el bloque de internacionalización carecía de importancia para uno de nuestros proyectos, por lo que simplemente lo excluimos y eso fue suficiente para que la lista fuera manejable. (Hay algunas sugerencias geniales en ese bloque que queríamos implementar pero no eran importantes para la aplicación en ese momento).

También puede crear algunos proyectos FxCop agrupando las excepciones hasta que obtenga el número en algo manejable ("corrige esto ahora", "soluciona esto pronto", "soluciona esto siempre").

Estoy bastante seguro de que pasé una semana sólida de exclusión/inclusión de infracciones hasta que obtuvimos una lista que era apropiada para nuestras políticas. Luego otro 2-3 solo arreglando violaciones. :-(

Answer 6

Lo que pasa es FxCop, es una excelente herramienta para el caso de uso específico para el que fue diseñado. Fue diseñado para ayudar a los desarrolladores de bibliotecas de clases. Así que si eres desarrollador Express o Infragistics y' Al crear una biblioteca de códigos para ser utilizada por los desarrolladores de todo el mundo, necesita una buena denominación, una buena globalización y una serie de otras cosas.

Por lo tanto, si nombra todas las formas como frmMain, FxCop se quejará porque se ve feo en una biblioteca de clases. Pero si solo está trabajando en una aplicación WinForms interna, no tiene que preocuparse. Del mismo modo, te volverás loco con todo lo relacionado con IFormatProvider, las sobrecargas de MessageBox que especifican la dirección del texto, y así sucesivamente. Pero a menos que esté creando código para una audiencia global, puede ignorarlos.

Lo importante es comprender la audiencia prevista de FxCop. Puede ignorar ciertas recomendaciones basadas en las formas en que difiere de esa audiencia.

Answer 7

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 proponen de manera predeterminada. 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 (es decir para evitar informes abrumadores), 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 sobre esta característica here. Éstos son, por ejemplo, dos notmycode consultas predeterminadas:

• Discard generated and designer Methods from JustMyCode
• Discard generated Types from JustMyCode

Para mantener el número de falsos positivos bajos, con CQLinq también se puede enfocar reglas resultan sólo en código agregado o código refactorizado, desde 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.