Análisis de código estático: ¿cuáles activar primero?

Question

Estamos usando VS2008 con el conjunto de reglas de análisis de código estático incorporado.
Tenemos una solución C # relativamente grande (más de 150 proyectos) y aunque algunos de los proyectos (& Lt; 20) están usando el análisis de código estático religiosamente, la mayoría no. Queremos comenzar a aplicar el análisis de código estático en todos los proyectos, pero habilitar todas las reglas crearía una distracción masiva para nuestros proyectos actuales. ¿Cuál de las muchas reglas de análisis de código estático disponibles deberíamos activar primero? ¿Qué reglas tienen la mayor inversión? Si pudiera darme su top 20 prioritario, lo agradecería mucho.
Gracias de antemano,
--Ed.S.

Answer 1

Las primeras reglas que debe activar para un proyecto son aquellas para las que aún no tiene ninguna violación en ese proyecto. Esto le permitirá evitar la introducción de nuevos problemas sin costarle ningún esfuerzo de limpieza adicional.

En cuanto al resto, dado que ya está utilizando el análisis de código en otros proyectos, su mejor aporte para qué reglas es más probable que se rompan con graves consecuencias es probablemente los desarrolladores que trabajan en esos proyectos. Si no tiene suficiente superposición entre proyectos para obtener comentarios significativos de los desarrolladores, puede considerar comenzar con las reglas que se incluyen en Reglas mínimas recomendadas de Microsoft conjunto de reglas en Visual Studio 2010.

Si está planeando en realidad limpiar las violaciones existentes en un proyecto determinado, es posible que desee considere usar FxCop en lugar de VS Code Analysis hasta que se complete la limpieza. Esto le permitiría activar las reglas inmediatamente mientras mantiene & Quot; para limpieza & Quot; exclusiones de infracciones existentes fuera de su código fuente.

Answer 2

Dado que los Studio son similares a las reglas de FxCop, puedo decirte cuáles activaría último .

Si la internacionalización no está en el horizonte, desactive las Reglas de globalización.

Desactive las Reglas de rendimiento inicialmente. Optimice cuando lo necesite.

Encaja a los demás con tu equipo y tus proyectos. Desactiva las reglas individuales que no son aplicables. En particular, es posible que sea necesario ajustar las reglas de nomenclatura.

EDITAR: Lo más importante es reducir el ruido. Si cada proyecto tiene 200 advertencias y permanece así durante meses, todos los ignorarán. Active las reglas que le interesan a su equipo, limpie el código para obtener el 100% de aprobación (o elimine las excepciones, y habrá excepciones; estas son pautas), luego haga cumplir el mantenimiento del código limpio.

Answer 3

Si va a localizar su proyecto / se va a utilizar en diferentes países, entonces definitivamente habilite las reglas de localización. Encontrará todas las llamadas a todo tipo de funciones de formato / análisis que no especifique CultureInfo. Los errores que involucran CultureInfo no especificados son difíciles de encontrar en las pruebas, pero realmente lo morderán por el culo, cuando su cliente francés le pregunte: ¿por qué su programa no funciona / falla en los números con & Quot;, & Quot ; como separador decimal.

Answer 4

En mi experiencia, las advertencias de análisis de código de todo tipo muestran errores o fallas "ocultas" en su código. Arreglarlos puede resolver algunos problemas reales. No he encontrado una lista de advertencias que me gustaría desactivar.

En cambio, los activaría en un proyecto a la vez y corregiría todas las advertencias en ese proyecto antes de pasar al siguiente.

Si desea desactivar las cosas, consideraría no verificar las reglas de nomenclatura (a menos que envíe una biblioteca, API u otros métodos expuestos externamente) y las reglas de globalización. (a menos que sus aplicaciones hagan un uso activo de la globalización). Depende un poco de su situación, lo que tiene sentido.

Answer 5

Estoy de acuerdo con la respuesta de Jeroen Huinink .

Activaría todas las reglas que crees que debería seguir un proyecto y las arreglaría lo antes posible. No tiene que arreglarlos todos ahora, pero a medida que avanza y arregla un defecto o refactoriza un método en un módulo, siempre puede limpiar los problemas encontrados por el análisis estático en ese método o módulo. El nuevo código debe cumplir con sus reglas y el código existente debe transformarse en adherencia lo más rápido posible, pero no necesita dejar todo para que eso suceda.

Su equipo de desarrollo también puede analizar los problemas de un proyecto y priorizarlos, tal vez presentando defectos en su sistema de seguimiento de problemas para los problemas más críticos para que sean abordados rápidamente y por el desarrollador apropiado.