Rangos de Complejidad Ciclomática [cerrado]

¿Cuáles son las categorías de complejidad ciclomática? Por ejemplo:

1-5: fácil de mantener
6-10: difícil
11-15: muy difícil
20+: casi imposible

Durante años, he asumido que 10 era el límite. Y cualquier cosa más allá de eso es mala. Estoy analizando una solución y estoy tratando de determinar la calidad del código. Ciertamente, la complejidad ciclomática no es la única medida, pero puede ayudar. Existen métodos con una complejidad ciclomática de más de 200. Sé que es terrible, pero tengo curiosidad por saber acerca de los rangos más bajos, como en mi ejemplo anterior.

Encontré esto :

Los valores de referencia mencionados anteriormente de Carnegie Mellon definen cuatro rangos aproximados para valores de complejidad ciclomática:

• Los métodos entre 1 y 10 se consideran simples y fáciles de entender.
• valores entre 10 y 20 indican código más complejo, que aún puede ser comprensible; sin embargo, las pruebas se vuelven más difíciles debido a la mayor cantidad de ramificaciones posibles que puede tomar el código
• Los valores de 20 y superiores son típicos del código con una gran cantidad de rutas de ejecución potenciales y solo se pueden comprender y probar completamente con gran dificultad y esfuerzo
• los métodos que van aún más alto, por ejemplo,> 50, son ciertamente imposibles de mantener

Al ejecutar métricas de código para una solución, los resultados muestran verde para cualquier cosa por debajo de 25. No estoy de acuerdo con esto, pero esperaba obtener otra entrada.

¿Existe una lista de rango generalmente aceptada para la complejidad ciclomática?

Supongo que depende de las capacidades de su personal de programación y, en gran parte, de su sensibilidad como gerente.

Algunos programadores son firmes defensores de TDD y no escribirán ningún código sin escribir primero una prueba unitaria. Otros programadores son perfectamente capaces de crear programas perfectamente buenos y libres de errores sin escribir una sola prueba unitaria. El nivel de complejidad ciclomática que cada grupo puede tolerar seguramente variará sustancialmente.

Es una métrica subjetiva; evalúe la configuración de su solución de Code Metrics y ajústela a un punto óptimo con el que se sienta cómodo y que le brinde resultados sensibles.

No hay categorías predefinidas y no sería posible la categorización por varias razones:

1. Algunas técnicas de refactorización simplemente mueven la complejidad de un punto a otro (no desde su código al marco o una biblioteca externa bien probada, sino de una ubicación a otra de la base de código). Ayuda a reducir la complejidad ciclomática y convence a su jefe (o cualquier persona que ama las presentaciones con gráficos en constante aumento) de que pasó su tiempo haciendo algo genial, pero el código sigue siendo tan malo como lo era anteriormente.

2. Por el contrario, a veces, cuando refactoriza un proyecto aplicando algunos patrones de diseño y programación, la complejidad ciclomática puede empeorar, mientras que se espera que el código refactorizado sea claro: los desarrolladores conocen los patrones de programación (al menos se espera que los conozcan), así que simplifica el código para ellos, pero la complejidad ciclomática no tiene esto en cuenta.

3. Algunas otras técnicas no refactorizadoras no afectan la complejidad ciclomática en absoluto, mientras que disminuyen severamente la complejidad de un código para desarrolladores. Ejemplos: agregar comentarios relevantes o documentación. "Modernizando" el código utilizando azúcar sintáctico.

4. Simplemente hay casos en los que la complejidad ciclomática es irrelevante. Me gusta el ejemplo dado por whatsisname en su comentario : algunas switchdeclaraciones grandes pueden ser extremadamente claras y reescribirlas de una manera más OOPy no sería muy útil (y complicaría la comprensión del código por parte de los principiantes). Al mismo tiempo, esas declaraciones son un desastre, en cuanto a la complejidad ciclomática.

5. Como Robert Harvey ya dijo anteriormente , depende del equipo mismo.

En la práctica, he visto código fuente que tenía una buena complejidad ciclomática, pero que era terrible. Al mismo tiempo, he visto código con alta complejidad ciclomática, pero no tuve mucho dolor al entenderlo.

Es solo que no hay ninguna herramienta que pueda indicar, sin problemas, qué tan bueno o malo es un determinado código o qué tan fácil es mantenerlo . Como no puede programar una aplicación que dirá que una pintura determinada es una obra maestra, y que otra debe descartarse, porque no tiene valor artístico.

Hay métricas que están divididas por diseño (como LOC o la cantidad de comentarios por archivo), y hay métricas que pueden dar algunas sugerencias en bruto (como la cantidad de errores o la complejidad ciclomática). En todos los casos, esos son solo consejos, y deben usarse con precaución.