Mejora tu código, código, código (III)

Continuamos con la mini serie sobre análisis estático de código con el último post de la serie.

Aquí tenéis el enlace al primero y al segundo.

Y es que en los anteriores post no hemos visto el trato con el código heredado o legacy code (ese gran hijo de ...). Y es que es un handicap muy común en nuestro día a día.

Si este código heredado no tiene contratos, vamos a obtener algunos warnings molestos del Static Checker. Sin embargo, la API de Code Contracts nos ofrece un pequeño workarround sobre esto.

Básicamente, este tipo de warnings son debidos a la falta de información - el Checker no es capaz de encontrar la información necesaria. Sin embargo, podemos dar algunos detalles.

Vamos a mirar el siguiente código:

Código con un Warning

Código con un Warning

El checker nos avisa de una posible referencia nula. Aparentemente la variable context está siendo usada sin haber sido inicializada. ¿Quién es el responsable del warning, el Checker u otra cosa?

En este caso, el aviso lo está dando ReSharper, cuyo motor de análisis identifica una posible referencia nula. ¿Pero porqué no nos lo da el Checker?, la respuesta es por la línea:

Contract.Assume(context!=null);

Y es que con esa línea le estamos diciendo al Checker que la variable context nunca va a ser nula. El Checker confía en nosotros y añade esa información a sus procesos. Resharper no ofrece soporte completo a los contratos de .NET, de ahí el aviso. Sin embargo, ReSharper soporta su propio sistema de anotaciones que podéis usar de la misma manera. Si queréis ver más detalles pasáos por aquí.

Uso óptimo del análisis estático de código.

El análisis estático es complejo, y no suele ser una ciencia exacta. Suele ocurrir que rellenamos nuestro código con información de contratos con la mejor intención, sólo para hacer que el tiempo de compilación se dispare. Para esto hay un par de soluciones que podríamos tomar para optimizar el uso de contratos y los análisis siguientes.

La primera es crear una configuración de compilación especial y habilitar las comprobaciones sólo en esa configuración. Compilamos en esa configuración de vez en cuando para obtener información, la corregimos los posibles problemas y continuamos trabajando sin el análisis estático.

La segunda es probar a usar contratos poco a poco. Aplicamos contratos de manera extensiva en el código, pero deshabilitamos los contratos a nivel de assembly. Esto lo asemos añadiendo el siguiente atributo en las propiedades del assembly:

[assembly:ContractVerification(false)]

Lo siguiente, es re-habilitar el checkeo de contratos sólo cuando estemos centrados en clases, métodos o assemblies.

Aviso

El análisis estático de código es una técnica que intenta evaluar el correcto funcionamiento de vuestro código sin ejecutarlo. Hay algunas herramientas que hacen esto. La primera es el compilador, otra es el Static Checker - un ejecutable que se integra en el proceso de compilación. En .NET, una herramienta especial aprende desde los contratos que tengáis, evalúa la información y nos muestra posibles errores y violaciones de contratos.

En el momento en el que la complejidad aumenta continuamente y el equipo de desarrollo se va quedando sin tiempo, integrar este tipo de herramientas salva algún tiempo de compilación, pero más importante, nos protege de errores feos en nuestro software.

 

Juan María Laó Ramos.