¿Qué es el análisis de código?
El análisis de código (anteriormente FxCop) es una herramienta de análisis estático que busca patrones comunes que pueden indicar que algo está mal en el código fuente. Por ejemplo, si una instancia de una clase que implementa IDisposableno se dispone correctamente, el análisis de código emitirá una advertencia:
private void DoSomething()
{
var connection = new SqlConnection(...);
this.ChangeSomeData(connection);
}
Esta es la implementación correcta del código anterior:
private void DoSomething()
{
using (var connection = new SqlConnection(...))
{
this.ChangeSomeData(connection);
}
}
Como cualquier herramienta de análisis estático, el análisis de código tiene la intención de encontrar patrones que sean engorrosos (o simplemente aburridos) para encontrarlos manualmente. Por ejemplo, en el ejemplo anterior, puede ser bastante aburrido para un desarrollador verificar si alguna clase que usa implementa IDisposable(o recordar todas las clases de .NET Framework que la implementan).
¿Qué proyectos califican?
Aunque está sujeto a falsos positivos, como cualquier herramienta de análisis estático, generalmente es beneficioso apuntar a cero advertencias para el código crítico para el negocio sin usar supresiones . Dentro de Visual Studio, el análisis de código se puede configurar para ejecutarse en tiempo de compilación; Si la configuración del proyecto también especifica que las advertencias deben tratarse como errores, las violaciones de las reglas de análisis de Código no pasarán desapercibidas.
Dado que el análisis estático puede llevar algún tiempo para proyectos medianos o grandes, a menudo es una buena idea moverlo de las máquinas del desarrollador al servidor de compilación TFS. Si bien ejecutar el análisis de código durante el precompromiso no es una buena idea (a diferencia de StyleCop), aún puede ejecutarse en la compilación y fallar si se encuentran advertencias.
Para el código no crítico para el negocio, el análisis de código puede ejecutarse manualmente desde Visual Studio o la línea de comandos. Las verificaciones y advertencias se pueden detallar en las propiedades del proyecto para satisfacer sus necesidades. Por ejemplo, las advertencias de globalización se pueden desactivar si su proyecto no está destinado a ser localizado.
Al igual que con StyleCop, es esencial decidir si el proyecto apuntará a cero advertencias del análisis de Código desde el comienzo del proyecto. Introducirlo en un proyecto existente puede ser demasiado doloroso.
¿Es diferente de StyleCop?
Tenga en cuenta que el análisis de código no es lo mismo que StyleCop . La primera diferencia es que el análisis de código funciona con el ensamblado compilado, mientras que StyleCop funciona con la fuente misma. La segunda (y más importante) diferencia es que el análisis de código busca patrones que pueden indicar un error, mientras que StyleCop simplemente aplica reglas de estilo, una convención simple utilizada por su equipo.
El análisis de código también es particularmente útil para principiantes que no conocen muy bien el idioma , ya que a menudo puede conducir a "¡Ajá!" momentos Por ejemplo, CA2105: los campos de matriz no deben leerse solo pueden llevar a alguien a descubrir que incluso si una matriz está marcada como de solo lectura, no la hace inmutable, ya que nada prohíbe cambiar los elementos dentro de la matriz. StyleCop no conduce a descubrimientos: no hay nada interesante en saber que los campos comienzan con una letra minúscula o que las llamadas locales deben tener el prefijo this.
Incluso si el análisis de código y StyleCop aplican algunas reglas (como CA1707: los identificadores no deben contener guiones bajos vs. SA1310: los nombres de campo no deben contener guiones bajos ), esas dos herramientas son complementarias y a menudo se usan una al lado de la otra.
Ya tenemos revisiones de código
La presencia de revisiones de código no es una razón para evitar el análisis de código. Tanto el análisis de código como StyleCop son excelentes para encontrar cosas automáticamente antes de una revisión de código. No hay nada peor que pasar una revisión de código identificando problemas de estilo o patrones problemáticos que podrían haberse encontrado automáticamente. Mantenga revisiones de código para cosas interesantes.
Otro aspecto es que los revisores humanos no son necesariamente buenos para detectar problemas encontrados por el análisis del Código. Por ejemplo, una instancia de implementación de una clase IDisposablepuede crearse en una ubicación y luego disponerse en una ubicación diferente. Un revisor tardará un tiempo en encontrarlo, mientras que una herramienta de análisis estático solo tardará unos pocos milisegundos en descubrirlo.
