Anotaciones para hacer cumplir las restricciones de complejidad y LCM ciclomática

Question

En el trabajo que estamos utilizando varias herramientas para capturar varias métricas (sobre todo la complejidad ciclomática y FCM). Utilizamos para obtener los indicadores de advertencia y para guiar los esfuerzos de refactorización de suscripción preferente. Ha sido muy beneficioso para aumentar la calidad del código.

Sin embargo, el proceso no está ligado a proceso de construcción. Se lleva a cabo por separado. Por otra parte, yo estoy buscando algo que puede hacerse intrínseca al código fuente (en contraposición a un proceso externo corrió en él.)

Hay alguien consciente de un grupo de anotaciones y la anotación de procesador configurable (s) que se pueden ejecutar desde el compilador, y que hará que la acumulación código de error si no cumple con el umbral ciclomática / FCM métricas?

supongo que podría correr ckjm, Checkstyle y PMD de experto / hormiga, pero algunos trabajos en el código fuente, y otros trabajan en código de bytes. Sería bueno tener una herramienta consolidada que funciona en el código fuente antes de que comience la compilación.

La otra cosa es que sería bueno si hay conjuntos de anotaciones que podrían impulsar este (para permitir la personalización que inevitablemente se necesitarán para casos de esquina.)

@LCOM3(Threshold=1.5)
public class SomeDumbPojo {... buch of gets/sets...}

// by default would be measured against a strict LCOM3
public class ActualBizClass
{
   @CYCLOMATIC_COMPLEXITY(Threshold=15)
   public void someFatIrreducibleMethod(){...}
}

A continuación, cuando se ejecute la herramienta, por defecto se aplica un estricto (y configurable) umbral de métrica, excepto en aquellos artefactos que están anotados con umbrales (esperemos documentado y legítimo) más relajado. Para algunos métodos que pueden / no deben ser reducidos, una complejidad ciclomática relajado tiene sentido. Para POJOs lisos w / o comportamiento, LCOMs necesitan estar relajado ... y así sucesivamente y así sucesivamente.

Buscando y buscando en Google como pude, no he podido encontrar nada (fuente de esperar abierta). Pero puede ser que también pido aquí por si alguien tiene conocimiento de nada por el estilo.

Gracias.

Answer 1

Sería bueno tener una herramienta consolidada que funciona en el código fuente antes de que comience la compilación.

No estoy muy seguro de lo que esto significa como el código tiene que ser compilado en algo con el fin para el análisis estático de trabajo. Todas estas herramientas tienen que ser capaces de compilar el código, ya sea en bytecode o algún tipo de árbol de sintaxis.

Yo sugeriría hacer que sea sencillo: PMD configurar a fallar la acumulación si las advertencias para Ciclomática complejidad u otras métricas de cruzar un umbral determinado. En lugar de anotar el método de la complejidad permitida (¿cómo derivar un valor aceptado? ¿Cuál es para evitar que alguien que accidentily aumenta la complejidad del 12 al 15 sólo se topa con la anotación), anotar que suprimir la advertencia por completo

@SuppressWarnings("PMD.CyclomaticComplexity")
public void someFatIrreducibleMethod() { ... }

Y a continuación, periódicamente se puede buscar en su base de código para los métodos con advertencias suprimidas que es posible que desee eliminar y refactor.

Como alternativa, el PMD tiene soporte para dejar comentarios en el código de una determinada sintaxis para marcar que audita la advertencia y cuando, si se desea proporcionar algún tipo de trazabilidad.

Answer 2

El SD Java Metrics Calcula herramienta de métrica más básicas (no FCM pero ciertamente la complejidad ciclomática), y se ejecuta desde la línea de comandos.

Se produce un archivo de salida XML, con métricas detalladas sobre los métodos y los resúmenes acumulativos de las jerarquías superiores que (Clase del paquete, subsistema). Usando XLST (o awk o perl o ...) Sería muy fácil para extraer la métrica que desea para el listado completo o para un método individual, y comprobar en contra de su umbral.