Métricas de código: complejidad ciclomática
Al trabajar con métricas de código, uno de los elementos menos entendidos parece ser 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 tener una idea de lo difícil que podría 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. En un nivel alto, 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, verá 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, cuantos más decisiones se tengan que 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 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 aumenta en uno:
Al cambiar la instrucción if a una instrucción switch con cuatro decisiones que se deben tomar entonces, pasa de las dos a seis originales:
Echemos un vistazo a una base de código más grande (hipotética).
Tenga en cuenta que la mayoría de los elementos, a medida que explora en profundidad la Products_Related clase, tienen un valor de uno pero un par de ellos tienen una complejidad de cinco. Por sí sola, esta diferencia podría no ser un gran problema, pero dado que la mayoría de los demás miembros tiene uno en la misma categoría, definitivamente deberías examinar más de cerca esos dos elementos y ver qué contienen. Puede echar un vistazo más de cerca haciendo clic con el botón derecho en el elemento y seleccionando Ir al código fuente en el menú contextual. Eche un vistazo más a Product.set(Product):
Dadas todas las instrucciones if, puede ver por qué la complejidad ciclomática está en un cinco. En este momento, puede decidir que este resultado es 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 usar como límite, sin embargo, sigue siendo algo controvertido. El límite original de 10 tal como lo propuso McCabe tiene pruebas de apoyo significativas, pero los límites tan altos como 15 también se han utilizado correctamente. Los límites de más de 10 deben reservarse para proyectos que tienen varias ventajas operativas sobre proyectos típicos, por ejemplo, personal experimentado, diseño formal, un lenguaje de programación moderno, programación estructurada, tutoriales de código y un plan de prueba completo. En otras palabras, una organización puede elegir un límite de complejidad mayor que 10, pero solo si está seguro de que sabe lo que está haciendo y está dispuesto a dedicar el esfuerzo de prueba adicional requerido por módulos más complejos". NIST235
Complejidad ciclomática y números de línea
Simplemente mirar el número de líneas de código por sí mismo es, en el mejor de los casos, un predictor muy amplio de la calidad del código. Hay cierta verdad básica en la idea de que cuantas más líneas de código tenga una función, más probable es que contenga errores. Sin embargo, al combinar la complejidad ciclomática con líneas de código, tiene una imagen mucho más clara de la posibilidad de errores.
Tal y como se describe en el Centro tecnológico de Software Assurance (SATC) en 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 tienden a tener la confiabilidad más baja. Los módulos con un tamaño bajo y una alta complejidad también son un riesgo de confiabilidad porque tienden a ser código muy terse, lo que es 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 extendido contiene un área de mantenimiento:
Dentro del área de mantenibilidad existe 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 más información sobre la regla, consulte CA1502
En resumen:
La conclusión es que un número de complejidad alta significa una mayor probabilidad de errores con un mayor tiempo para mantener y solucionar problemas. Eche un vistazo más detenidamente a las funciones que tienen una alta complejidad y decida si deben refactorizarse para que sean menos complejas.
Citas
MCCABE5
McCabe, T. y A. Watson (1994), Complejidad del software (CrossTalk: The Journal of Defense Software Engineering).
NIST235
Watson, A. H., & McCabe, T. J. (1996). Pruebas estructuradas: metodología de pruebas que usa la métrica de complejidad ciclomática (publicación especial de NIST 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). Métricas de software y confiabilidad (Actas del Simposio Internacional ieee sobre ingeniería de confiabilidad de software). Consultado el 14 de mayo de 2011, del sitio web de Penn State University: https://citeseerx.ist.psu.edu/pdf/31e3f5732a7af3aecd364b6cc2a85d9495b5c159