Interpretar correctamente las métricas de código

Las métricas de código son medidas orientadas a estimar el tamaño, complejidad e incluso calidad de nuestro código. Actualmente, Visual Studio permite calcular 4 métricas desde las versiones Community, lo cual permite a cualquier desarrollador analizar sus desarrollos según lo programan y antes de subirlo a un repositorio de código. El desarrollador puede obtener una primera medida de la mantenibilidad o complejidad de lo que ha desarrollado antes de subirlo. También nos permiten obtener una estimación rápida del tamaño de un proyecto heredado o si un módulo está fuertemente acoplado o bien cohesionado.

Por otro lado, aunque sean herramientas que nos indican la calidad de un desarrollo, siempre es mucho más recomendable contar con herramientas como SonarQube que hacen un análisis más detallado.

Métricas de código incluidas en Visual Studio

La herramienta de Code Metrics incluida en Visual Studio calcula las métricas a 4 niveles: proyecto, espacio de nombres, clase y método.

En Visual Studio se analizan por defecto las siguientes métircas:

• Índice de mantenibilidad: Es un valor calculado a partir de otras métricas. La herramienta nos ofrece un valor entre 0 y 100 (de 0 a 10 es poco mantenible, de 10 a 20 es moderadamente mantenible y por encima de 20 es mantenible).
• Complejidad ciclomática: Es una medida del número de caminos independientes dentro de un fragmento de código.
• Profundidad de herencia: El número de clases heredadas hasta llegar a la clase raíz.
• Acoplamiento de clases: Indica con cuantas otras clases estamos relacionado o conectados.
• Líneas de código: Las líneas de código generadas por el IL (Intermediate language) sin contar comentarios o saltos de línea.

Quality Gates recomendados

Para cada una de estas métricas, existen unos valores recomendados. Exceder estos valores puede señalarnos un posible mal diseño:

• Índice de mantenibilidad: Como comentábamos anteriormente, a partir de 10 se supone que el código es moderadamente mantenible y a partir de 20 es mantenible. Sin embargo, no debería ser difícil que este valor sea superior a 20 y deberíamos intentar que el valor sea siempre superior a 50.
• Complejidad ciclomática: Se suele recomendar no exceder de 20 a nivel de método. Para cálculos o algoritmos complejos puede ser fácil superarlo, en cualquier caso, a partir de 50 se suele considerar como código no testeable.
• Profundidad de herencia: Se recomienda que el valor sea menor de 4, a partir de ese valor, el desarrollador pierde la referencia de las clases de las que está heredando.
• Acoplamiento de clases: Es más difícil de encontrar recomendaciones de está métrica, pero se suele recomendar valores inferiores a 30 a nivel de método y de 80 a nivel de clase.
• Líneas de código: Se debe intentar evitar que los métodos pasen de 20 líneas de código.

Interpretar los resultados (Cuidado con los sumatorios y medias)

Las métricas que nos arroja Code Metrics son realmente interesante a nivel de método y en segundo lugar de clase. Los valores calculados a nivel de espacio de nombres y proyecto son una media en el caso del índice de mantenibilidad o el sumatorio de lo que contienen en el caso del resto. Nos pueden servir para comparar dos proyectos, por ejemplo, cuál tiene más líneas de código o mayor complejidad ciclomática, pero siempre es recomendable revisar los resultados a nivel de clase y método. Un proyecto con un índice de mantenibilidad de 60 puede parecer que tiene buena mantenibilidad, pero puede esconder métodos o clases con un valor por debajo de 20. O por ejemplo, otro proyecto con una sola clase con una complejidad ciclomática de 100 puede hacer que no nos fijemos en él, mientras que otro proyecto puede tener 50 clases y una suma de 500 de esa métrica.

Insisto, es importante que una vez encontremos esas clases con métricas mejorables, analicemos también si los valores son correctos. Por ejemplo, si un proyecto tiene código autogenerado, deberíamos excluir estas métricas ya que nos puede dar valores de líneas de código elevadas cuando esas líneas no las vamos a mantener de forma directa. Otro ejemplo puede ser que nos encontremos clases con una profundidad de herencia elevada, cuando realmente están heredando de un objeto del framework (como el caso de los ViewModel en WPF).

Más métricas y cómo obtenerlas

Visual Studio nos ofrece estas métricas por defecto, pero existen muchísimas más: Bugs por línea de código, cobertura de test, número total de clases, tiempo de carga de la aplicación, etc…

Existen extensiones como Roslyn Metrics que nos permiten calcular hasta 32 métricas distintas también desde el Visual Studio. Visual Studio nos permite también con la herramienta de Code Clones localizar y contar código duplicado (aunque todavía no cuenta con una opción de exportar tan potente como la de Code Metrics).

Y como comentábamos anteriormente, pero fuera del ámbito de Visual Studio, contamos con SonarQube, la mejor opción para tener nuestro código bien inspeccionado.

 Javier Sanz

.NET Architect | Soluciones Microsoft | SOGETI ESPAÑA