Sonar es quizás la plataforma más popular para medir la calidad del código (evaluación estática y de caja blanca, principalmente). Sonar obtiene métricas del código, trabaja con muchos lenguajes,y para ello utiliza plugins y otras herramientas (PMD, Checkstyle, etc.) y muestra los resultados en un cuadro de mando.
La herramienta es libre, potente y muy popular. Pero… la documentación sobre la misma es escasa, muy escasa, y, si bien he encontrado decenas de implantaciones en empresas… apenas he encontrado equipos (muy pocos) que sepan de verdad qué significa cada métrica del cuadro de mando de Sonar, y ese el motivo de este post: aclarar el significado del cuadro de mando de Sonar.
Vamos allá.
El cuadro de mando de Sonar
A través de la interfaz de Sonar podemos ver de forma detallada los puntos débiles de nuestro proyecto como errores potenciales en el código, escasez de comentarios, clases demasiado complejas, escasez de cobertura de las pruebas unitarias, y más.
Realmente el cuadro de mando que aparece en Sonar, es el resultado de analizar nuestro código con los plugins o herramientas que hemos instalado en el programa. Sonar trae instalados por defecto herramientas de análisis dinámico y estático de código (caja blanca) como Checkstyle, PMD, Findbugs, etc., además de implementaciones propias del equipo de Sonar, para obtener distintas métricas del software.
A continuación puedes ver la imagen típica del cuadro de mando de métricas de Sonar.
Figura 1.Vista del cuadro de mando principal de un proyecto en Sonar
Podemos configurar las métricas que queremos que se muestren en el cuadro de mando o añadir nuevas métricas de plugins que instalemos.
Las métricas que muestra el cuadro de mando de Sonar por defecto para cada proyecto son las que veremos a continuación.
1. Complejidad
Cuando en Sonar se habla de complejidad se refiere a complejidad ciclomática (te recomiendo aquí este post complejidad ciclomática, o la métrica esencial para evaluar el diseño software). La parte del cuadro de mando que trata sobre ello es la que se muestra en la siguiente figura.
Figura 2. Complejidad ciclomática
1.1. ¿Cómo calcula Sonar la complejidad ciclomática?
Sonar, al analizar nuestro código para calcular la complejidad ciclomática, mantiene un contador. Cuando el flujo de una función se altera, es decir, se produce un salto, este contador de la complejidad aumenta en 1. Cada función tiene como mínimo una complejidad de 1, aunque no hayamos programado nada en ella (se suma 1 por la llamada al método).
En el caso de Java este valor se obtendría de la siguiente forma:
- Cuando Sonar encuentra las palabras clave “if”,”for”,”while”,”case”,”catch”, “throw”,”return” (sin ser la última sentencia de un método), “&&”, “||”, “?”, “else”, se aumenta el contador global de complejidad ciclomática en 1. También se aumenta en 1 el contador por la cabecera del método.
- Los métodos get() y set() (accesores) no entran en esta cuenta, es decir, Sonar no aumenta en 1 la complejidad ciclomática total al encontrar la cabecera de un método de este tipo.
Un ejemplo del cálculo de la complejidad ciclomática en Sonar para Java sería el de la Figura 3.
Figura 3. Ejemplo del cálculo de la complejidad ciclomática en Java
Para ver como calcula Sonar la complejidad ciclomática en otros lenguajes se puede ver la tabla de la esta página.
En lo que refiere a complejidad el cuadro de mando muestra tres tipos: la de método, la de clase, la de fichero y la total.
- Complejidad/método:Es la media de la complejidad por método, es decir, la suma de la complejidad/método de cada clase dividido entre el número de métodos totales de nuestro software.
El valor que aparece en la Figura 2 es una media global de nuestro programa analizado. Si queremos ver este valor desglosado, accediendo a alguna clase del sistema nos encontraremos una sección parecida a la siguiente:
Figura 4. Lista de métricas de una clase
El valor de complejidad/método que aparece en cada clase, es el valor total de complejidad ciclomática de esa clase dividido entre el número de métodos. En el ejemplo de la Figura 2 sería:
- Complejidad/clase: Es la media de la complejidad de todas las clases, es decir, la suma de la complejidad ciclomática total de cada clase (obtenida como la suma de la complejidad de cada uno de sus métodos), dividida entre el número de clases.
- Complejidad/fichero: Es la media de la complejidad por fichero.
- Complejidad total (Total): Es la complejidad ciclomática total del sistema (es decir, el sumatorio de la complejidad ciclomática de todos los métodos de nuestro software).
De todos estos valores que nos muestra el cuadro de mando principal de Sonar (ver Figura 2), los valores de los que se puede deducir más información acerca de la calidad nuestro sistema son de la complejidad/método y por clase.
1.2. Valores recomendados de complejidad ciclomática
Saber que un programa tiene un valor muy alto de complejidad ciclomática (lo que hemos llamado complejidad ciclomática total, véase en la Figura 2 con un valor 68313) no nos aporta demasiado a la hora de decidir qué acciones llevar a cabo para mejorar nuestro software.
Esto ocurre porque no existe un valor umbral aproximado de la complejidad ciclomática total que un software debería tener (no todo el software tiene el mismo tamaño, ergo, no podemos realizar una estimación de un valor de complejidad ciclomática que no deberían sobrepasar todos los programas).
Sin embargo si podríamos decir que la complejidad ciclomática de cada método, y en consecuencia también la media de la complejidad ciclomática/método no debería sobrepasar el valor de 30. No obstante el valor adecuado de complejidad ciclomática dependerá de lo que establezca la organización, no siempre deberá tomarse como referencia ese valor de 30. Pero podemos decir que 30 en un método ya es bastante.
Por ello, le parámetro del cuadro de mando de más utilidad es la complejidad/método, que, igualmente, no debería ser más de 30.
Por último, un valor muy alto de complejidad ciclomática por clase, debido a su propia definición, nos indica síntomas de un mal diseño, hace que el código sea más difícil de entender y dificulta la cobertura de pruebas unitarias, puesto que habría que realizar más test para probar cada uno de los caminos independientes extra de nuestro código. En este post complejidad ciclomática, o la métrica esencial para evaluar el diseño software, viene todo explicado.
Una buena ayuda para ver esto es emplear las nubes de palabras (Figura 5) que ofrece Sonar, a las que accedemos desde el menú de Herramientas -> Nubes. En este apartado si seleccionamos Complejidad ciclomática, podremos saber a partir de un vistazo rápido, qué clases tienen mayor complejidad ciclomática del sistema.
Figura 5. Nube de palabras Sonar
Puedes ver la continuación de esté post aquí: Cómo interpretar métricas de calidad software: entendiendo el cuadro de mando de Sonar (2/3)
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
dos problemas que he visto con Sonar:
– No detecta menos de 10 lineas de codigo duplicadas
Es frecuente ver codigo duplicado de pocas lineas.
– No detecta codigo duplicado cambiando las variables.
Por ejemplo (codigo tonto pero se coje la idea)
aaa = 1
bbb = aaa * 2
ccc = 1
ddd = ccc * 2
Esto no lo detecta.
Interesante serie de post Javier.
Por aportar algo, un problema que creo que tiene Sonar para la complejidad es que realiza la media y esto puede enmascarar métodos con complejidad muy mala. Supongamos un producto con 1000 métodos. Si 30 de ellos tienen una complejidad muy alta, pero el resto la tienen media/baja, el resultado final de la métrica de sonar será que la complejidad de método (y de ahí para arriba) será aceptable.
Saludos
cierto, y Sonar tampoco te localiza de un vistazo los métodos más complejos. Te indica los clases mas complejas, pero no los métodos.
Buenas
Es cierto todo lo que comentáis, y veo también un fallo que Sonar no muestre la complejidad ciclomática a nivel de método de forma tan sencilla como en los otros casos.
Sin embargo hay un truco para verla: Hay una regla de codificación de Sonar que busca los métodos cuya complejidad es mayor que un cierto valor (este valor es configurable). Si cambiamos este valor límite a un valor muy pequeño, los métodos de las clases incumplirán esa regla de codificación, por lo que se mostrará su valor de complejidad ciclomática.
Saludos
Hola a todos, creo que el valor max de 30 para la C.C de un método es mucho, nosotros manejamos un valor bastante menor por método(10) y además controlamos que las clases no tengan más de 30 métodos. ¿Qué os parece? Saludos.
Hola Vicente,
cierto, para nosotros 30 también es muy alta. Un valor de 10 como propones está genial. Nosotros en nuestro laboratorio lo tenemos calibrado hasta 16 por método.
En el caso del número de métodos por clase (aunque también depende del lenguaje y de si utilizas frameworks que te autogeneren código y métodos), si te recomendaría intentar reducir un poco. Nosotros lo intentamos mantener entre 12 y 18 métodos por clase.
Por otro lado Enric, es cierto, creo que sonar no te detecta el método concreto, que es realmente lo que luego habría que arreglar si quieres bajar la complejidad 😉 de ahí el problema que comentaba.
Un saludo.
Hola,
En línea con lo que comenta Vicente, el artículo de McCabe, donde presentó la complejidad ciclomática en el 76 hablaba de un valor de 10.
Saludos