¿Tiene sentido calcular la complejidad ciclomática / relación de líneas de código?

8

En general, el índice de mantenibilidad se basa en muchos factores. Por ejemplo, en Visual Studio, se basa en la complejidad ciclomática, la profundidad de la herencia, el acoplamiento de clases y las líneas de código; esos cuatro valores deben ser lo más bajos posible.

Al mismo tiempo, nunca he visto, ni en las herramientas de métricas de código ni en los libros, la comparación entre solo la complejidad ciclomática (CC) y las líneas de código (LC).

¿Tiene sentido calcular tal proporción? ¿Qué información da sobre el código? En otras palabras, ¿es mejor disminuir más el CC que el LC para tener una relación más baja?

Lo que noto es que para proyectos pequeños, la relación CC / LC es baja (⅓ y menor). En otras palabras, LC es alto y CC es bajo. En proyectos grandes, CC / LC es en la mayoría de los casos mayor de ½. ¿Por qué?

— Arseni Mourzenko
fuente

13

La única métrica de calidad de código válida es WTFs / minuto;)

1

Su última predicción (proyectos pequeños x grandes) probablemente depende de la plataforma y la cantidad de código repetitivo que uno debe escribir para obtener un proyecto mínimo en ejecución. Usando la API Win32 sin procesar, la cantidad de repeticiones al código real es alta para proyectos pequeños, por ejemplo. Esto infla el número de línea de código. Puede seleccionar algunos proyectos aleatorios de código abierto y hacer un diagrama de dispersión de CC x LC. Tal vez puedas encontrar algo útil fuera de esto.

— Vitor Py

La relación que sugiere es una OMI interesante, pero quiero sugerir que reemplace las líneas de código (LOC) con puntos de función (FP) o puntos de caso de uso (UCP) y vea qué obtiene.

— M.Sameer

4

De http://en.wikipedia.org/wiki/Cyclomatic_complexity

Les Hatton afirmó recientemente (Keynote en TAIC-PART 2008, Windsor, Reino Unido, septiembre de 2008) que McCabe Cyclomatic Complexity tiene la misma capacidad de predicción que las líneas de código. [11]

La relación tiene aproximadamente la misma capacidad de predicción que cualquiera de las dos utilizadas por separado.

— S.Lott
fuente

1

Estoy en desacuerdo. La Complejidad Ciclomática (CC) está claramente correlacionada con las Líneas Lógicas de Código (LLOC). Cuanto más grande sea su proyecto, mayor será su complejidad. Esto es obvio. Pero CC / LLOC no tiene correlación con el tamaño de un proyecto (he visto ejemplos concretos). Esta relación depende de tres cosas: lenguaje y marco utilizados, complejidad funcional del proyecto y estilo de código. Si los dos primeros elementos no se pueden cambiar fácilmente, el tercero puede ser una indicación clara de la calidad del código.

— Alexandre Butynski

6

Hay una métrica de complejidad ciclomática por enunciados fuente: se llama densidad de complejidad ciclomática . Esta métrica se puede utilizar para estimar el tiempo de mantenimiento y el esfuerzo necesarios para proyectos de software.

— Thomas Owens
fuente

3

Como se señaló en una respuesta anterior, esta afirmación en la respuesta aceptada es claramente incorrecta.

La relación tiene aproximadamente la misma capacidad de predicción que cualquiera de las dos utilizadas por separado.

Varios investigadores han encontrado que la densidad CC tiene sentido, aunque no parece haber ganado una popularidad significativa entre los profesionales. Hay evidencia de dos académicos conocidos en el área de métricas de software de que la relación (densidad de complejidad ciclomática = CC / KLOC) es un predictor mucho mejor de productividad de mantenimiento que el CC o KLOC solo.

GK Gill y CF Kemerer, "Densidad de complejidad ciclomática y productividad de mantenimiento de software", en IEEE Transactions on Software Engineering, vol. 17, no. 12, págs. 1284-1288, diciembre de 1991. doi: 10.1109 / 32.106988

Hay muchos otros que se han basado en este trabajo para refinar las métricas basadas en la densidad CC. Dos ejemplos:

T. Andersson, K. Enholm y A. Törn. Medida independiente de la longitud de la complejidad del software. En M. Ross, CA Brebbia, C. Staples y J. Stapleton (eds.) Segunda Conferencia Internacional sobre Gestión de Calidad de Software, Vol. 1, Gestión de Sistemas de Calidad, 1994.
JP Mittal, Pradeep Bhatia y Harish Mittal. 2009. Evaluación de la productividad del mantenimiento del software utilizando lógica difusa. SIGSOFT Softw. Ing. Notas 34, 5 (octubre de 2009), 1-4. DOI = http://dx.doi.org/10.1145/1598732.1598739

— Nikos Houssos
fuente

¿Y debería ser alto, bajo, en un rango específico, o alguna idea nebulosa de "razonable" para el mejor de los casos, de acuerdo con eso?

— Deduplicador

El artículo establece que en módulos particulares de los sistemas investigados los valores estaban entre 0.10 y 0.12. He observado en aplicaciones web de producción bastante complejas que piden refactorizar valores entre 0.18-0.20. Sospecharía que cualquier cosa alrededor de 0,20 podría ser demasiado complejo, mientras que los valores más cercanos a 0,10 indican un nivel de densidad de complejidad lo suficientemente bajo; sin embargo, se necesitan más datos para obtener resultados más seguros.

— Nikos Houssos

1

Lo siento pero no estoy de acuerdo con esta declaración:

La relación tiene aproximadamente la misma capacidad de predicción que cualquiera de las dos utilizadas por separado.

Una relación claramente no es lo mismo que una métrica individual. Basado en datos empíricos, Hatton afirma que CC es proporcional a XLOC con una relación constante de aproximadamente 0.25 (ver diapositiva 17) para su conjunto de datos específico. Por lo tanto, ya sea que su XLOC sea 60 o 400, su relación CC: XLOC será de aproximadamente 0.25 (ignorando las desviaciones estadísticas en números más altos). Por lo tanto, la relación no es predictiva en absoluto.

— Brian Rowe
fuente

seguramente es más probable que obtenga una desviación estadística con números pequeños

— jk.