10 | marzo | 2012

Hi,

Today I was thinking to write about some of the new features of Static Code Analysis in Visual Studio 11, but better get this post of the draft folder and make it public.

When working on a project, regardless of the tool that we use for the analysis of static code (Code Analysis, FxCop, etc.) it is always advisable to apply the following rules

At least a minimum set of analysis rules apply to all projects. Based on the principle of "least da a stone", this helps us protect us from future mistakes. In the case of Code Analysis, the set of "Minimun Rules" is ideal.
You have to work in a continuous integration environment, this so am assuming. In the event that the analysis process consume too much time in local, it is advisable not to perform validation of Code Analysis in local. That Yes, in the process of continuous integration is due to force static code analysis
Fundamental. Do not ignore the Warnings in the builds, dedicate time and solve the problems detected in them. Many times I prefer to change the mode of Warning Notice error, only to force to resolve the problems detected on static code analysis.
Finally, and optional. If someone wants to have local detail, activates the process of Code Analysis in local. Visual Studio allows you to do in 2 clicks.

Saludos @ Home

El Bruno

References:

List of tools for static code analysis

http://en.Wikipedia.org/wiki/List_of_tools_for_static_code_analysis

Buenas,

tenía pensado escribir sobre algunas de las novedades de Static Code Analysis en Visual Studio 11, pero mejor saco este post del draft y lo publico.

Cuando trabajamos en un proyecto, independientemente de la herramienta que utilicemos para el análisis de código estático (Code Analysis, FxCop, etc.) siempre es recomendable aplicar las siguientes reglas

Como mínimo aplicar un conjunto mínimo de reglas de análisis a todos los proyectos. Basado en el principio de “menos da una piedra”, esto nos ayuda a protegernos de errores a futuro. En el caso de Code Analysis, el set de “Minimun Rules” es lo ideal.
Tienes que trabajar en un entorno de Integración Continua, a esto lo doy por hecho. En el caso de que el proceso de análisis consuma mucho tiempo en local, lo recomendable es no realizar la validación de Code Analysis en local. Eso sí, en el proceso de integración continua se debe forzar el análisis de código estático
Fundamental. No ignorar los Warnings en las builds, dedicarle tiempo y solucionar los problemas que se detectan en los mismos. Muchas veces prefiero cambiar el modo de aviso de Warning a Error, solamente para forzar a que se resuelvan los problemas que detecta en análisis de código estático.
Finalmente, y opcional. Si alguien quiere tener el detalle local, activa el proceso de Code Analysis en local. Visual Studio lo permite hacer en 2 clics.

Saludos @ Home

El Bruno

References:

List of tools for static code analysis

http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis