¿Cuál es la más alta complejidad ciclomática de cualquier función a mantener? Y cómo usted va sobre refactorización?

Question

Yo estaba haciendo un poco de exploración de un sistema heredado mantengo, con NDepend (gran herramienta a verlo ), el otro día. Mis hallazgos casi me hicieron rociar la boca llena de café encima de la pantalla. Los 3 mejores funciones de este sistema calificados por la complejidad descendente ciclomática son:

1. SomeAspNetGridControl.CreateChildControls (CC de 171 !!!)
2. SomeFormControl.AddForm (CC de 94)
3. SomeSearchControl.SplitCriteria (CC de 85)

Me refiero a 171, wow !!! ¿No debería ser inferior a 20 o algo? Así que esto me hizo pensar. ¿Cuál es la función más compleja a mantener o haber reprogramado? Y cómo usted va sobre refactorización un procedimiento de este tipo?

Nota:. El CC Medí es sobre el código, no el IL

Answer 1

Esto es cosa de niños en comparación con algunos de COBOL 1970 de la vendimia en los que trabajé hace algunos años. Se utilizó el herramienta McCabe para mostrar gráficamente la CC para una parte del código. La salida de impresión era puro negro debido a que las líneas que muestran las trayectorias funcionales fueron tan densamente empaquetados y espagueti-como. No tener una figura, pero tenía que ser mucho mayor que 171.

¿Qué hacer

código completo (primera edición):

Si la puntuación es:

• 0-5 - la rutina es probablemente muy bien
• 6-10 - empezar a pensar en la manera de simplificar la rutina
• 10+ - break parte de la rutina en una segunda rutina y llamarlo desde la primera rutina

Podría ser una buena idea para escribir pruebas unitarias como se rompe la rutina original.

Answer 2

Esto es para el código C / C ++ envío actualmente en un producto:

el valor de CC más alta que podía identificar de forma fiable (es decir, no sospecho la herramienta está añadiendo erróneamente valores de complejidad de los casos no relacionados de principal (...)):

• una función de procesamiento de imágenes: 184
• un cargador elemento base de datos con la verificación: 159

También hay una subrutina de prueba con CC = 339, pero eso no es estrictamente parte del producto del envío. me hace pensar aunque cómo uno podía verificar el caso (s) prueba implementado allí ...

y sí, los nombres de las funciones han sido suprimidos para proteger a los culpables:)

¿Cómo cambiarlo:

Ya existe un esfuerzo en marcha para remediar este problema. Los problemas se deben principalmente a dos causas fundamentales:

1. código espagueti (sin encapsulación, un montón de copiar y pegar)
2. código proporcionado al grupo de productos por parte de algunos científicos de ingeniería sin capacitación en carpintería de construcción de software reales / /.

El método principal es la identificación de piezas cohesivos de los espaguetis (tirar de un hilo :)) y romper las funciones looooong en los más cortos. A menudo hay asignaciones o transformaciones que se pueden extraer en una función o una clase de ayuda / objeto. El cambio a STL utilizando en lugar de los contenedores y los iteradores construidos a mano puede cortar una gran cantidad de código también. Std :: string en lugar de C-strings ayuda mucho.

Answer 3

He encontrado otra opinión sobre esto de esta entrada del blog que parece tener sentido y trabajar para mí cuando se compara contra diversas bases de código. Sé que es un tema muy obstinado, por lo que tu caso es distinto.

• 1-10 - simple, no hay mucho riesgo
• 11-20 - complejo, bajo riesgo
• 21-50 - demasiado complejo, de riesgo medio, la atención
• Más de 50 - demasiado complejo, no puede probar, de alto riesgo