refactoring - software - ¿Considera que la complejidad ciclomática es una medida útil?
programa para calcular la complejidad ciclomatica (15)
+1 para los valores de la lista de resultados de kenj0418.
Lo peor que he visto fue un 275. Hubo un par de otros más de 200 que pudimos refactorizar a CC mucho más pequeños; aún estaban altos, pero los empujó más atrás en la fila. No tuvimos mucha suerte con la 275 bestia: era (probablemente todavía lo es) una red de declaraciones if y switch que era demasiado compleja. Su único valor real es como un paso adelante cuando deciden reconstruir el sistema.
Las excepciones al CC alto con las que me sentía cómodo eran las fábricas; OMI, se supone que tienen un CC alto, pero solo si solo están creando objetos simples y regresando.
He estado jugando con la medición de la complejidad ciclomática de una gran base de código.
La complejidad ciclomática es la cantidad de trayectorias linealmente independientes a través del código fuente de un programa y hay muchas herramientas gratuitas para el idioma de su elección.
Los resultados son interesantes pero no sorprendentes. Es decir, las partes que sé que son las más peludas fueron de hecho las más complejas (con una calificación de> 50). Pero lo que me resulta útil es que se asigna un número concreto de "maldad" a cada método como algo a lo que puedo apuntar cuando decido por dónde comenzar la refactorización.
¿Usas complejidad ciclomática? ¿Cuál es el código más complejo que encontraste?
Conocerás la complejidad cuando la veas. Lo principal de este tipo de herramienta es útil para marcar las partes del código que estaban escapando a su atención.
Después de understanding lo que significa, ahora he comenzado a usarlo como "prueba". Hasta ahora, he encontrado que es útil, porque generalmente el CC alto va de la mano con el Flecha Antipatrón , lo que hace que el código sea más difícil de leer y comprender. Todavía no tengo un número fijo, pero NDepend alerta sobre todo por encima de 5, lo que parece un buen comienzo para investigar los métodos.
Es útil para mí de la misma manera que Big-O es útil: sé lo que es, y puedo usarlo para entender si un método es bueno o malo, pero no necesito calcularlo para cada función que he escrito.
Creo que las métricas más simples, como LOC, son al menos tan buenas en la mayoría de los casos. Si una función no cabe en una pantalla, casi no importa qué tan simple sea. Si una función toma 20 parámetros y hace 40 variables locales, no importa si su complejidad ciclomática es 1.
Es ideal para ayudar a identificar candidatos para la refactorización, pero es importante mantener su juicio. Apoyaría los rangos de kenj0418 para guías de poda.
Frecuentemente mido la complejidad ciclomática de mi código. Descubrí que me ayuda a detectar áreas de código que están haciendo demasiado. Tener una herramienta que señale los puntos conflictivos en mi código consume mucho menos tiempo que tener que leer miles de líneas de código tratando de descubrir qué métodos no están siguiendo el SRP.
Sin embargo, descubrí que cuando hago un análisis de complejidad ciclomática en el código de otras personas, generalmente me produce sentimientos de frustración, angustia y enojo general cuando encuentro un código con complejidad ciclomática de los 100. ¿Qué obliga a las personas a escribir métodos que tengan varios miles de líneas de código en ellos?
Hasta que no haya una herramienta que pueda funcionar bien con las plantillas C ++ y las técnicas de meta-programación, no es de mucha ayuda en mi situación. De todos modos solo recuerda eso
"No todas las cosas que cuentan se pueden medir, y no todas las cosas que se pueden medir cuentan" Einstein
Así que recuerde pasar cualquier información de este tipo a través del filtro humano también.
Hay una métrica de Java llamada CRAP4J que combina empíricamente la complejidad ciclomática y la cobertura de prueba JUnit para llegar a una sola métrica. Él ha estado investigando para tratar de mejorar su fórmula empírica. No estoy seguro de cuán extendido está.
La Complejidad Ciclomática es solo un componente de lo que podría llamarse Complejidad Fabricada. Hace un tiempo, escribí un artículo para resumir varias dimensiones de la complejidad del código: lucha contra la complejidad fabricada
Las herramientas son necesarias para ser eficientes en el manejo de la complejidad del código. La herramienta NDepender para el código .NET le permitirá analizar muchas dimensiones de la complejidad del código, incluidas métricas de código como: Complejidad Ciclomática, Profundidad de anidamiento, Falta de Cohesión de Métodos, Cobertura por Pruebas ...
incluyendo el análisis de dependencias e incluyendo un lenguaje ( Code Query Language ) dedicado a preguntar, ¿qué es complejo en mi código y escribir una regla?
Me temo que para el lenguaje del proyecto que más me gustaría métricas como esta, LPC , no hay, de hecho, muchas herramientas gratuitas para producirlo. Entonces no, no es tan útil para mí.
No lo he usado por un tiempo, pero en un proyecto anterior realmente me ayudó a identificar posibles puntos problemáticos en el código de otra persona (¡no sería mío, por supuesto!)
Al encontrar el área para verificar, encontré rápidamente numerosos problemas (¡también muchos de GOTOS!) Con lógica y algún código WTF realmente extraño.
La complejidad ciclomática es excelente para mostrar áreas que probablemente estén haciendo mucho y, por lo tanto, rompan la responsabilidad principal. Idealmente, estos deberían dividirse en múltiples funciones
Recientemente comenzamos a usarlo. Usamos NDepend para hacer un análisis de código estático y mide la complejidad ciclomática. Estoy de acuerdo, es una buena manera de identificar métodos para refactorizar.
Lamentablemente, hemos visto # por encima de 200 para algunos métodos creados por nuestros desarrolladores en el extranjero.
Refactorizamos sin piedad y utilizamos la complejidad de Cyclomatic como una de las métricas que obtiene el código en nuestra ''lista de resultados''. 1-6 no marcamos por complejidad (aunque podría ser cuestionada por otros motivos), 7-9 es cuestionable, y cualquier método por encima de 10 se considera malo, a menos que se demuestre lo contrario.
Lo peor que hemos visto fue 87 de una monstruosa cadena if-else-if en algún código heredado que tuvimos que asumir.
En realidad, la complejidad ciclomática se puede usar más allá de los umbrales de nivel de método. Para empezar, un gran método con alta complejidad se puede dividir en varios métodos pequeños con menor complejidad. Pero, ¿realmente ha mejorado la base de código? De acuerdo, puede obtener una legibilidad algo mejor con todos los nombres de métodos. Pero la lógica condicional total no ha cambiado. Y la lógica condicional total a menudo se puede reducir al reemplazar condicionales con polimorfismo .
Necesitamos una métrica que no se vuelva verde por la mera descomposición del método. Yo llamo a esto CC100 .
CC100 = 100 * (Complejidad ciclomática total de la base de código) / (Total de líneas de código)
Sí, lo usamos y también lo he encontrado útil. Tenemos una gran base de código heredada para domesticar y descubrimos una gran complejidad ciclomática. (387 en un método!). CC lo dirige directamente a áreas que vale la pena refactorizar. Usamos CCCC en código C ++.