Pregunta

He estado jugando con la medición de la complejidad ciclomática de una base de gran código.

Ciclomática complejidad es el número de caminos independientes linealmente a través del código fuente de un programa y hay un montón de herramientas gratuitas para el idioma de su elección.

Los resultados son interesantes pero no sorprendente. Es decir, las partes que conozco que es el más peludo eran, de hecho, el más complejo (con una calificación de> 50). Pero lo que me resulta útil es que un número "maldad" concreto se asigna a cada método como algo que pueda apuntar a la hora de decidir dónde empezar refactorización.

¿Utiliza complejidad ciclomática? ¿Cuál es el más complejo trozo de código que has encontrado?

¿Fue útil?

Solución

refactorizar sin piedad, y usamos Ciclomática complejidad como uno de los indicadores que Obtiene el código en nuestra lista de favoritos. 1-6 no lo hacemos bandera de la complejidad (aunque se podría conseguir cuestionado por otras razones), 7-9 es cuestionable, y cualquier método de más de 10 se supone que es malo a menos que se demuestre lo contrario.

Lo peor que hemos visto fue 87 a partir de una monstruosa if-else-si de alguna cadena de código heredado tuvimos que tomar el relevo.

Otros consejos

En realidad, la complejidad ciclomática puede ser objeto de un uso más allá de los umbrales de nivel de método. Para empezar, un método grande con alta complejidad puede ser dividida en varios métodos pequeños con menor complejidad. Pero lo que realmente ha mejorado la base de código? Por supuesto, usted puede conseguir algo mejor legibilidad de todos esos nombres de método. Pero la lógica condicional total que no ha cambiado. Y la lógica condicional total de frecuencia puede reducirse mediante reemplazando condicionales con polimorfismo .

Necesitamos una métrica que no cambia a verde por mera descomposición método. Yo llamo a esto CC100 .

CC100 = 100 * (ciclomática complejidad total de código base) / (total de líneas de código)

Es útil para mí de la misma manera que las grandes-O es útil: Yo sé lo que es, y puede utilizarlo para conseguir una sensación visceral de si un método es bueno o malo, pero no necesito para calcular que para cada función que he escrito.

Creo métricas simples, como LOC, son al menos tan buena en la mayoría de los casos. Si una función no cabe en una pantalla, que casi no importa lo simple que es. Si una función de 20 parámetros y hace 40 variables locales, no importa si es su complejidad ciclomática 1.

Recientemente hemos empezado a utilizarlo. Utilizamos NDepend a 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 la refactorización.

Lamentablemente, hemos visto # 's por encima de 200 para algunos métodos creados por nuestros desarrolladores en alta mar.

Hasta que no haya una herramienta que puede trabajar bien con las plantillas de C ++, y las técnicas de programación meta, que no es de mucha ayuda en mi situación. De todas formas sólo recuerda que

  

"no todas las cosas que cuentan pueden ser   medido, y no todas las cosas que pueden   recuento ser medido"   Einstein

Así que recuerde a pasar cualquier información de este tipo a través del filtrado humana también.

Usted sabrá complejidad cuando lo ves. Lo principal de este tipo de herramienta es útil para marcar es las partes del código que se escapaba a su atención.

Con frecuencia medir la complejidad ciclomática de mi código. He descubierto que me ayuda a descubrir puntos de código que están haciendo demasiado. Tener una herramienta de señalar los puntos calientes en mi código es mucho menos tiempo que tener que leer a través de miles de líneas de código tratando de averiguar qué métodos no están siguiendo la SRP.

Sin embargo, he encontrado que cuando hago un análisis de complejidad ciclomática el código de otras personas por lo general conduce a sentimientos de frustración, angustia, irritabilidad y cuando encuentro de código con la complejidad ciclomática en el 100 de. Lo que obliga a las personas a escribir métodos que tienen varios miles de líneas de código en ellos?!

Es una gran ayuda para identificar candidatos para la refactorización, pero es importante mantener su juicio alrededor. Me apoyo rangos de kenj0418 para guías de poda.

Hay una métrica de Java llamada CRAP4J que combina empíricamente complejidad ciclomática y cobertura de las pruebas JUnit para llegar a un único métrico. Lo ha estado haciendo la investigación para tratar de mejorar su fórmula empírica. No estoy seguro de lo extendida que está.

No he utilizado en un tiempo, pero en un proyecto anterior que realmente ayudado a identificar posibles puntos débiles en alguien vigilara de código (no sería la mía, por supuesto!)

Al encontrar problemas numerious a la salida, me encontré rápidamente de la zona (también un montón de GOTOS le creemos!) Con la lógica y algo de código WTF realmente extraño.

Ciclomática complejidad es grande para mostrar las áreas que probablemente están haciendo mucho y, por tanto, romper la única prinicpal cargo del cliente. Estos idealmente deben ser divididas en funciones haya numerosas

Me temo que por el lenguaje del proyecto para el que me gusta más métricas de este tipo, LPC , no hay, de hecho, un montón de herramientas gratuitas para producirlo disponible. Así que no, no es tan útil para mí.

1 para golpear de kenj0418 valores de la lista.

El peor que he visto era un 275. Había un par de otros más de 200 que hemos sido capaces de refactorizar a CC mucho más pequeñas; que todavía eran altas, pero que consiguieron los empujaron más atrás en la fila. No tuvimos mucha suerte con la bestia 275 - era (probablemente sigue siendo) una red de si- y desconexión declaraciones que era simplemente demasiado compleja. No es más que el valor real es como un paso a través cuando deciden reconstruir el sistema.

Las excepciones a alta CC que estaba cómodo con eran fábricas; OMI, que se supone que tienen un alto CC pero sólo si sólo están haciendo la creación de objetos simples y regresar.

Después de la comprensión lo que significa, que ya han comenzado a utilizar sobre una base de "prueba". Hasta ahora he encontrado que es útil, porque por lo general alta CC va de la mano con el flecha anti-patrón, lo que hace código más difícil de leer y entender. No tengo un número fijo todavía, pero NDepend está alertando a todo por encima de 5, que parece un buen punto de partida para investigar métodos.

Sí, usamos y he encontrado que es útil también. Tenemos una base de código heredado grande como para dominar y encontramos alaraming alta complejidad ciclomática. (387 en un método!). CC puntos directamente a las áreas que vale la pena refactorizar. Utilizamos CCCC en código C ++.

Ciclomática La complejidad es sólo un componente de peso lo que podría llamarse fabricada Complejidad. Hace un tiempo, escribí un artículo para resumir varias dimensiones de la complejidad del código: Fighting fabricada Complejidad

Herramientas se necesita para ser eficiente en el manejo de la complejidad del código. La herramienta NDepend de código .NET le permitirá analizar muchas dimensiones de la complejidad del código incluyendo métricas de código como: Ciclomática complejidad, profundidad de anidamiento, la falta de cohesión de los métodos, la cobertura mediante pruebas ...

incluyendo el análisis de dependencias e incluyendo una lengua ( Código Query Language ) dedicada a preguntar , lo que es complejo en mi código, y para escribir regla?

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top