Seguro que muchos conocéis la posibilidad de Visual Studio de realizar análisis de código, tal y como hacíamos anteriormente con ‘FxCop’, pero me gustaría empezar el post poniendo de manifiesto una serie de puntos por los que considero que esta tarea es algo que deberíamos realizar continuamente.
¿Por qué debemos usar Code Analyzer?
- En primer lugar porque la revisión de código es parte del ciclo de vida en el desarrollo de Software.
- Dejar la revisión de código para el último momento es mucho más costoso en tiempo y en recursos que realizarlo como un proceso continuo.
- Es una forma sencilla de ‘educar’ al equipo de desarrollo viendo el porque no se deben realizar ciertas codificaciones.
- Fomenta el uso de buenas prácticas.
- Mejora la calidad y el mantenimiento del código que realizamos.
Por defecto con Visual Studio ya tenemos un buen número de reglas predefinidas que podemos pasar a las revisiones de nuestro código, estas reglas se pueden englobar dentro de alguna de las siguientes categorías:
- Naming Conventions
- Globalization
- Design Rules
- Security
- Performance
- Reliability
- Portability
- Mobility
- Interoperability
- Maintainability
- Usage
Para activar el análisis de código en nuestros proyectos es suficiente con activar la casilla de ‘Enable Code Analysis’ en la pestaña Code Analysis de las propiedades del proyecto.
Una vez activado el análisis de código en cada compilación del proyecto se realizará el análisis mostrando los ‘warnings’ o errores en el caso de que el código no cumple alguna de las reglas seleccionas a pasar.
¿Cómo trabaja Code Analyzer?
Al contrario que otros analizadores de código ‘Code Analyzer’ es un analizador que trabaja sobre el ‘Manifiesto’ y el código ‘IL’ por lo que podríamos decir que es un analizador binario, por lo tanto es necesario como primer paso la compilación de los ensamblados a analizar, usa ‘Instrospección’ no ‘Reflexión’ por lo tanto no es necesario para el análisis cargar en el ‘Runtime’ los ensamblados ni bloquearlos para realizar el análisis, esto es una ventaja respecto a la ‘Reflexión’ y encima es un proceso mucho más óptimo que la Reflexión.
¿Puedo crear mis propias reglas en Code Analyzer?
Efectivamente es posible crear reglas propias de empresa o grupos de trabajo y que estas mismas se integren perfectamente en Visual Studio 2005, me gustaría comentar que esto no está soportado por Microsoft si bien existen unos cuantos enlaces de los que nos podemos descargar ejemplos de reglas para Code Analyzer.
Creando una regla personalizada para Code Analyzer
Objetivos:
Analizar las propiedades de ‘Solo escritura’. Si bien esta regla es más que discutible, no la toméis como una norma, es un ejemplo sencillo de realizar.
Pasos:
- Creamos un proyecto de librería de clases
- Agregamos las referencias necesarias para trabajar con Code Analyzer
- FxCopSdk.dll
- FxCopCommon.dll
- Microsoft.Cci.dll
Situadas en el directorio de instalación de Visual Studio 2005 en
Team ToolsStatic Analysis ToolsFxCop
Una vez agregadas las referencias para crear una regla únicamente tenemos que heredar de la clase de BaseInstrospectionRule que tenemos en Microsoft.FxCop.Sdk.Instrospection
public class WriteOnlyPropertyRule
: BaseIntrospectionRule // necesario para crear una regla de FxCop
{
//El resource de BaseInstrospectionRule es el [NombreEnsamblado].[Nombre Archivo XMl]
public WriteOnlyPropertyRule()
: base(«WriteOnlyPropertyRule», » GeeksDemo.GeeksDemo.RuleData», typeof(SlaterLabsRules.WriteOnlyPropertyRule).Assembly)
{
}
public override ProblemCollection Check(Member member)
{
Property property = member as Property;
if (property == null) return null;
if (property.GetPropertyInfo().CanWrite && !property.GetPropertyInfo().CanRead)
{
//ie, si la propiedad es de solamente escritura.
//En el Resolutions del Xml hay una serie de parametros {0} {1} que podremos rellenar para cada caso mediante
//este array de strings
string[] args = { property.Name.Name };
base.Problems.Add(new Problem(GetResolution(args)));
}
return base.Problems;
//return base.Check(member);
}
public override TargetVisibilities TargetVisibility
{
get
{
return TargetVisibilities.All;
}
}
}
El siguiente paso es el de incluir como recurso un archivo XML con la información de la regla, el nombre de este archivo XML debe de estar en consonancia con el parámetro de resource que hemos incluido en la construcción de BaseInstrospectionRule de nuestra regla, para ver como se construyen estos archivos XML podemos usar ‘Reflector’ para ver las reglas que tenemos por defecto en el directorio de reglas de Code Analyzer Microsoft Visual Studio 8Team ToolsStatic Analysis ToolsFxCopRules. En nuestro ejemplo el archivo XML como recurso es el siguiente:
<?xml version=«1.0« encoding=«utf-8« ?>
<Rules FriendlyName=«Geeks Rules«>
<Rule TypeName=«WriteOnlyPropertyRule« Category=«GeeksDemo.Coding« CheckId=«SL0001«>
<Name>No Propiedades de solo escritura</Name>
<Description>Acerca de las propiedades de solo escritura.</Description>
<Url>http://www.geeks.com</Url>
<Resolution>Elimina el método Set de la propiedad ‘{0}’</Resolution>
<Email>unai@plainconcepts.com</Email>
<MessageLevel Certainty=«99«>Warning</MessageLevel>
<FixCategories>NonBreaking</FixCategories>
<Owner/>
</Rule>
</Rules>
Despegando nuestra regla
El proceso de despliegue de la regla es muy sencillo basta con situar nuestro ensamblado en el directorio de reglas que comentamos en el paso anterior para que ya podamos hacer uso de ellas.
Conclusiones
Espero que os haya resultado de interés este Post y os animo a que propongamos y creemos nuevas reglas.