Métricas de código: complejidad ciclomática

Al trabajar con métricas de código, uno de los elementos menos comprendidos parece ser la complejidad ciclomática. Básicamente, con la complejidad ciclomática, los números más altos son malos y los números más bajos son buenos. Puede usar la complejidad ciclomática para hacerse una idea de lo difícil que puede ser cualquier código determinado para probar, mantener o solucionar problemas, así como una indicación de la probabilidad de que el código genere errores. A rasgos generales, determinamos el valor de la complejidad ciclomática contando el número de decisiones tomadas en el código fuente. En este artículo, empezará con un ejemplo sencillo de complejidad ciclomática para comprender rápidamente el concepto y, a continuación, examinará información adicional sobre el uso real y los límites sugeridos. Por último, hay una sección de citas que se pueden usar para profundizar más en este tema.

Ejemplo

La complejidad ciclomática se define como medir "la cantidad de lógica de decisión en una función de código fuente" NIST235. En pocas palabras, cuanto más decisiones se deban tomar en el código, más compleja será.

Vamos a verlo en acción. Cree una nueva aplicación de consola y calcule inmediatamente las métricas de código; para ello, vaya a Analizar > Calcular las métricas de código para la solución.

Observe que la complejidad ciclomática está en 2 (el valor más bajo posible). Si agrega código que no es de decisión, observe que la complejidad no cambia:

Si agrega una decisión, el valor de complejidad ciclomática sube en 1:

Al cambiar la instrucción if a una instrucción switch con 4 decisiones que se van a tomar, pasa del original de 2 a 6:

Echemos un vistazo a una base de código más grande (hipotética).

Observe que la mayoría de los elementos, a medida que profundiza en la clase Products_Related, tienen un valor de 1, pero un par de ellos tienen una complejidad de 5. Por sí mismo, esto podría no ser un gran problema, pero dado que la mayoría de los demás miembros tienen un 1 en la misma clase, definitivamente debería analizar más detalladamente esos dos elementos y ver lo que hay en ellos. Para ello, haga clic con el botón derecho en el elemento y elija Ir al código fuente en el menú contextual. Analicemos Product.set(Product) más detenidamente:

Dadas todas las instrucciones if, puede ver por qué la complejidad ciclomática está en un 5. En este momento, puede decidir que se trata de un nivel aceptable de complejidad, o puede refactorizar para reducir la complejidad.

El "número mágico"

Al igual que con muchas métricas de este sector, no hay ningún límite exacto de complejidad ciclomática que se ajuste a todas las organizaciones. Sin embargo, NIST235 indica que un límite de 10 es un buen punto de partida:

"El número preciso que se va a utilizar como límite, sin embargo, sigue siendo algo controvertido. El límite original de 10 propuesto por McCabe cuenta con pruebas de apoyo significativas, pero también se han utilizado con éxito límites de hasta 15. Los límites superiores a 10 deben reservarse para proyectos que presenten varias ventajas operativas con respecto a los proyectos típicos; por ejemplo, personal experimentado, diseño formal, un lenguaje de programación moderno, programación estructurada, recorridos por el código y un plan de pruebas exhaustivo. En otras palabras, una organización puede elegir un límite de complejidad superior a 10, pero solo si está segura de que sabe lo que hace y está dispuesta a dedicar el esfuerzo adicional de pruebas que requieren los módulos más complejos". NIST235

Complejidad ciclomática y números de línea

El número de líneas de código por sí solo es, en el mejor de los casos, un indicador muy amplio de la calidad del código. Hay algo de verdad en la idea de que cuantas más líneas de código tenga una función, más probabilidades hay de que contenga errores. Sin embargo, cuando se combina la complejidad ciclomática con las líneas de código, se tiene una idea mucho más clara del potencial de errores.

Según la descripción del Centro de Tecnología de Aseguramiento del Software (SATC) de la NASA:

"El SATC ha encontrado que la evaluación más eficaz es una combinación de tamaño y complejidad ciclomática. Los módulos con una complejidad alta y un tamaño grande suelen tener la confiabilidad más baja. Los módulos de bajo tamaño y alta complejidad también son un riesgo para la confiabilidad porque suelen ser código muy escueto, difícil de cambiar o modificar". SATC

Análisis de código

El análisis de código incluye una categoría de reglas de mantenimiento. Para obtener más información, consulte Reglas de mantenimiento. Al usar el análisis de código heredado, el conjunto de reglas de directrices de diseño extendidas contiene un área de mantenimiento:

Dentro del área de mantenibilidad hay una regla para la complejidad:

Esta regla emite una advertencia cuando la complejidad ciclomática alcanza 25, por lo que puede ayudarle a evitar una complejidad excesiva. Para obtener más información sobre la regla, consulte CA1502.

Resumen

En resumidas cuentas, un número de complejidad elevado implica una mayor probabilidad de errores, con el consiguiente aumento del tiempo de mantenimiento y resolución de problemas. Examine detenidamente las funciones que tengan una complejidad elevada y decida si deben refactorizarse para hacerlas menos complejas.

Citas

MCCABE5

McCabe, T. and A. Watson (1994), Software Complexity (CrossTalk: The Journal of Defense Software Engineering).

NIST235

Watson, A. H., & McCabe, T. J. (1996). Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric (NIST Special Publication 500-235). Consultado el 14 de mayo de 2011, del sitio web de McCabe Software: http://www.mccabe.com/pdf/mccabe-nist235r.pdf

SATC

Rosenberg, L., Hammer, T., Shaw, J. (1998). Software Metrics and Reliability (Proceedings of IEEE International Symposium on Software Reliability Engineering). Consultado el 14 de mayo de 2011, del sitio web de Penn State University: https://citeseerx.ist.psu.edu/pdf/31e3f5732a7af3aecd364b6cc2a85d9495b5c159