language-agnostic architecture cyclomatic-complexity

language agnostic - ¿Qué es la Complejidad ciclomática?



language-agnostic architecture (14)

Cada punto de decisión en una rutina (loop, switch, if, etc ...) esencialmente se reduce a una sentencia if equivalente. Para cada uno, if tiene 2 rutas de códigos que se pueden tomar. Entonces, con la primera rama hay 2 rutas de código, con la segunda hay 4 rutas posibles, con la 3a hay 8 y así sucesivamente. Hay al menos 2 rutas de código N ** donde N es el número de ramas.

Esto hace que sea difícil comprender el comportamiento del código y probarlo cuando N crece más allá de un número pequeño.

Un término que veo de vez en cuando es "Complejidad ciclomática". Aquí en SO, vi algunas preguntas sobre "cómo calcular el CC de Language X" o "Cómo hago Y con la cantidad mínima de CC", pero no estoy seguro de entender realmente de qué se trata.

En el sitio web de NDepend , vi una explicación que básicamente dice "El número de decisiones en un método. Cada if, for, && etc. agrega +1 al CC" puntaje "). ¿Eso es realmente? Si es así, ¿por qué? ¿Esto es malo? Veo que uno podría querer mantener la cantidad de declaraciones if bastante bajas para mantener el código fácil de entender, pero ¿realmente esto es todo?

¿O hay algún concepto más profundo para eso?


Considere el gráfico de flujo de control de su función, con una ventaja adicional desde la salida a la entrada. La complejidad ciclomática es la cantidad máxima de cortes que podemos realizar sin separar el gráfico en dos partes.

Por ejemplo:

function F: if condition1: ... else: ... if condition2: ... else: ...

Gráfico de flujo de control

Probablemente puedas ver intuitivamente por qué el gráfico vinculado tiene una complejidad ciclomática de 3.


Eso es más o menos Sin embargo, cada rama de una instrucción "caso" o "cambio" tiende a contar como 1. En efecto, esto significa que CC detesta las declaraciones de casos y cualquier código que los requiera (procesadores de comando, máquinas de estado, etc.).


Eso es todo, la idea es que un método que tiene un bajo CC tiene menos horquillas, bucles, etc., lo que hace que el método sea más complejo. Imagine revisar 500,000 líneas de código, con un analizador y ver un par de métodos que tienen una mayor cantidad de CC. Esto le permite enfocarse en refactorizar esos métodos para una mejor comprensión (también es común que un CC alto tenga una alta tasa de errores)


La Complejidad ciclomática realmente es solo una palabra de moda aterradora. De hecho, es una medida de la complejidad del código utilizada en el desarrollo de software para señalar partes más complejas del código (es más probable que tenga fallas y, por lo tanto, debe probarse con mucho cuidado y exhaustividad). Puede calcularlo usando la fórmula E-N + 2P, pero le sugiero que lo calcule automáticamente con un complemento. He oído hablar de una regla empírica que debe esforzarse por mantener el CC por debajo de 5 para mantener una buena legibilidad y facilidad de mantenimiento de su código.

Recientemente experimenté con el plugin de Eclipse Metrics en mis proyectos Java, y tiene un archivo de ayuda realmente agradable y conciso que se integrará con su ayuda Eclipse y puede leer más definiciones de varias medidas de complejidad, consejos y trucos. en mejorar tu código.


La complejidad ciclomática mide el número de veces que debe ejecutar un bloque de código con parámetros variables para ejecutar cada ruta a través de ese bloque. Un conteo más alto es malo porque aumenta las posibilidades de que los errores lógicos escapen de su estrategia de prueba.


La complejidad ciclomática se calcula utilizando el gráfico de flujo de control. El Número de medida cuantitativa de trayectos linealmente independientes a través del código fuente de un programa se denomina Complejidad Ciclómica (if / if else / for / while)


La complejidad ciclomatric es básicamente una métrica para descubrir áreas de código que necesitan más atención para la mantenibilidad. Sería básicamente una entrada a la refactorización. Definitivamente da una indicación del área de mejora del código en términos de evitar el bucle anidado profundo, las condiciones, etc.


Las respuestas proporcionadas hasta el momento no mencionan la correlación de la calidad del software con la complejidad ciclomática. Las investigaciones han demostrado que tener una métrica de complejidad ciclomática más baja debería ayudar a desarrollar software que sea de mayor calidad. Puede ayudar con los atributos de calidad del software de legibilidad, mantenibilidad y portabilidad. En general, se debe tratar de obtener una métrica de complejidad ciclomática de entre 5 y 10.

Una de las razones para usar métricas como la complejidad ciclomática es que, en general, un ser humano solo puede realizar un seguimiento de aproximadamente 7 (más o menos 2) piezas de información simultáneamente en su cerebro. Por lo tanto, si su software es demasiado complejo con varias rutas de decisión, es poco probable que pueda visualizar cómo se comportará su software (es decir, tendrá una métrica de complejidad ciclomática alta). Esto probablemente conduzca al desarrollo de software erróneo o montado en errores. Puede encontrar más información sobre esto here y también en Wikipedia .


No estoy al tanto de un concepto más profundo. Creo que generalmente se considera en el contexto de un índice de mantenimiento. Cuantas más ramas hay dentro de un método particular, más difícil es mantener un modelo mental del funcionamiento de ese método (generalmente).

Los métodos con mayor complejidad ciclomática también son más difíciles de obtener una cobertura de código completa en pruebas unitarias. (Gracias Mark W !)

Eso trae todos los otros aspectos de la mantenibilidad, por supuesto. Probabilidad de errores / regresiones / etc. Sin embargo, el concepto central es bastante directo.


Otro punto interesante que he escuchado:

Los lugares en su código con las sangrías más grandes deben tener el CC más alto. En general, estas son las áreas más importantes para garantizar la cobertura de las pruebas porque se espera que sean más difíciles de leer / mantener. Como se señala en otras respuestas, estas son también las regiones de código más difíciles para garantizar la cobertura.


Sí, eso es realmente. Cuantas más rutas de ejecución pueda tomar su código, más cosas se deben probar y mayor es la probabilidad de error.


Wikipedia puede ser tu amiga en este: Definición de complejidad ciclomática

Básicamente, debes imaginar tu programa como un gráfico y luego

La complejidad es (...) definida como:

M = E − N + 2P

dónde

  • M = complejidad ciclomática,
  • E = el número de bordes del gráfico
  • N = la cantidad de nodos del gráfico
  • P = la cantidad de componentes conectados

CC es un concepto que intenta capturar qué tan complejo es su programa y qué tan difícil es probarlo en un solo número entero.


Cyclocmatic complexity = Number of decision points + 1

Los puntos de decisión pueden ser sus enunciados condicionales como if, if ... else, switch, for loop, while loop, etc.

El siguiente cuadro describe el tipo de la aplicación.

  • La complejidad ciclomática se encuentra entre 1 y 10  Para ser considerada aplicación normal

  • La complejidad ciclomática se encuentra entre 11 y 20  Aplicación moderada

  • Complejidad ciclomática se encuentra 21 - 50  aplicación arriesgada

  • Complejidad ciclomática se encuentra más de 50  aplicación inestable