Métricas de código

Las métricas de código son un conjunto de medidas de software que proporcionan a los programadores una mejor visión del código que están desarrollando. Aprovechando las ventajas de las métricas del código, los desarrolladores pueden entender qué tipos o métodos deberían rehacerse o más pruebas. Los equipos de desarrollo pueden identificar los posibles riesgos, comprender el estado actual de un proyecto y realizar un seguimiento del progreso durante el desarrollo de software.

Valores de las métricas de código. Microsoft

Autores:

Thomas J.McCabe – Complejidad ciclomática

Paul C. Jorgensen – Software Testing: A Craftsman’s Approach.

Medidas de software

• Índice de mantenimiento -calcula un valor de índice entre 0 y 100 que representa su relativa facilidad de mantenimiento del código. Un valor alto significa mayor facilidad de mantenimiento. Las clasificaciones de colores, pueden utilizarse para identificar rápidamente los puntos conflictivos en el código. Una clasificación en verde entre 20 y 100 e indica que el código tiene buen mantenimiento. Una calificación amarilla es entre 10 y 19 e indica que el código es moderadamente fácil de mantener. Una clasificación de color rojo es una clasificación entre 0 y 9 e indica un mantenimiento baja. Para obtener más información, consulte el intervalo del índice de mantenimiento y el significado entrada de blog.

The maintainability index has been re-set to lie between 0 and 100.  How and why was this done?
The metric originally was calculated as follows: Maintainability Index = 171 - 5.2 * ln(Halstead Volume) - 0.23 * (Cyclomatic Complexity) - 16.2 * ln(Lines of Code)
This meant that it ranged from 171 to an unbounded negative number.  We noticed that as code tended toward 0 it was clearly hard to maintain code and the difference between code at 0 and some negative value was not useful.   I\'ll post some tech ed sample code showing very low maintainability or you can try on your own code to verify.  As a result of the decreasing usefulness of the negative numbers and a desire to keep the metric as clear as possible we decided to treat all 0 or less indexes as 0 and then re-base the 171 or less range to be from 0 to 100. Thus, the formula we use is:

Maintainability Index = MAX(0,(171 - 5.2 * ln(Halstead Volume) - 0.23 * (Cyclomatic Complexity) - 16.2 * ln(Lines of Code))*100 / 171)
On top of that we decided to be conservative with the thresholds.  The desire was that if the index showed red then we would be saying with a high degree of confidence that there was an issue with the code.  This gave us the following thresholds (as mentioned in this blog previously):
For the thresholds we decided to break down this 0-100 range 80-20 so that we kept the noise level low and only flagged code that was really suspicious. We have:
0-9 = Red
10-19 = Yellow
20-100 = Green

https://blogs.msdn.microsoft.com/codeanalysis/2007/11/20/maintainability-index-range-and-meaning/

• Complejidad ciclomática -mide la complejidad del código estructural. Se crea, calculando el número de rutas de acceso de código diferente en el flujo del programa. Un programa que tiene el flujo de control complejo requiere más pruebas para lograr una buena cobertura de código y es difícil de mantener. Para obtener más información, consulte el entrada de Wikipedia para complejidad ciclomática.

Ejemplo: Complejidad ciclomática :

Para calcular la complejidad ciclomática del núdulo de un programa, usaremos la fórmula:

V(G) = e – n + 2 
Where
 e is total number of edges 
 n is total number of nodes 

Para el diagrama anterior, la complejidad ciclomática es:

e = 10 
n = 8 
Cyclomatic Complexity = 10 - 8 + 2 = 4 

Según P. Jorgensen, la complejidad ciclomática de un módulo no debe ser mayor a 10.

Rangos de valores de complejidad ciclomática

• Profundidad de herencia -indica el número de diferentes clases que heredan entre sí, remontándose a la clase base. Profundidad de herencia es similar a la clase en que un cambio en una clase base puede afectar a cualquiera de sus clases heredadas de acoplamiento. Cuanto mayor sea este número, mayor será la herencia y mayor será la posibilidad de que las modificaciones de la clase base dar lugar a importantes cambios. Profundidad de herencia de un valor bajo es bueno y un valor alto es incorrecto.
• Acoplamiento de clases -mide el acoplamiento a las clases únicas a través de parámetros, variables locales, tipos de valor devuelto, llamadas a métodos, las creaciones de instancias genérica o de plantilla, clases base, implementaciones de interfaz, los campos definidos en los tipos externos, y decoración de atributo. Buen diseño de software dicta que deben tener alta cohesión y acoplamiento bajo los tipos y métodos. El significativo acoplamiento indica un diseño que es difícil reutilizar y mantener debido a sus interdependencias en otros tipos. Para obtener más información, consulte el el acoplamiento de clases entrada de blog.
• Líneas de código -indica el número aproximado de líneas del código. El recuento se basa en el código IL y, por tanto, no es el número exacto de líneas en el archivo de código fuente. Un recuento alto podría indicar que un tipo o método está intentando hacer demasiado trabajo y debe dividirse. También podría indicar que el tipo o método podría ser difícil de mantener.

Métricas de SonarQube

Ver fuente: https://docs.sonarqube.org/latest/user-guide/metric-definitions/