Аннотации для обеспечения циклической сложности и ограничений LCOM

Question

На работе мы используем несколько инструментов для захвата нескольких показателей (в основном, циклической сложности и LCOM). Мы используем их для получения предупреждающих флагов и для руководства упреждающими усилиями по рефакторингу. Это было очень полезно в повышении качества кода.

Однако процесс не связан с процессом сборки. Он проводится отдельно. Более того, я ищу что-то, что может быть сделано для исходного кода (в отличие от внешнего процесса, на котором он работает.)

Кто-нибудь знает группу аннотаций и настраиваемых обработчиков аннотаций, которые могут запускаться из компилятора и что приведет к сбою сборки, если код не соответствует пороговым циклическим/LCOM-меткам?

Я думаю, я мог бы запустить ckjm, checkstyle и pmd из maven/ant, НО некоторые работы с исходным кодом, а другие работают на байт-код. Было бы неплохо иметь один консолидированный инструмент, который работает с исходным кодом до начала компиляции.

Другое дело, что было бы хорошо, если есть наборы аннотаций, которые могли бы способствовать этому (возможности настройки, которые неизбежно будут необходимы для угловых случаев.)

@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(){...} 
} 

Тогда, когда мы запустите инструмент, по умолчанию применяет строгий (и настраиваемый) метрический порог, за исключением тех артефактов, которые аннотируются (на наш взгляд, документированными и законными) более расслабленными порогами. Для некоторых методов, которые не могут/не должны быть уменьшены, расслабленная цикломатическая сложность имеет смысл. Для простых POJO без повода LCOM необходимо смягчить ... и т. Д. И т. Д.

Взгляд и поиск, как я мог, я не смог найти ничего (надеюсь, с открытым исходным кодом). Но я мог бы также спросить здесь, на всякий случай, если кто-то знает об этом.

Спасибо.

Answer 1

Было бы неплохо иметь один консолидированный инструмент, который работает с исходным кодом перед началом компиляции.

Я не совсем уверен, что это означает, как код должен быть составлен в то для того, чтобы статический анализ для работы. Все эти инструменты должны иметь возможность компилировать ваш код либо в байт-код, либо в какое-то дерево синтаксиса.

Я бы предложил оставить его простым: настройте PMD для сбоя сборки, если любые предупреждения для Cyclomatic Complexity или других показателей пересекают заданный порог. Вместо того, чтобы аннотировать метод с допустимой сложностью (как бы вы получили приемлемую ценность?), Что должно помешать тому, кто случайно увеличил сложность с 12 до 15, чтобы просто набить аннотацию), аннотировать его для полного предупреждения предупреждения

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

А затем периодически вы можете искать свою кодовую базу для методов с подавленными предупреждениями, которые вы можете удалить и реорганизовать.

В качестве альтернативы PMD имеет возможность оставлять комментарии в коде в определенном синтаксисе, чтобы отметить, кто проверял это предупреждение, и когда, если вы хотите предоставить некоторую отслеживаемость.

Answer 2

Инструмент SD Java Metrics вычисляет самые основные показатели (не LCOM, но, конечно, Cyclomatic complex), и запускается из командной строки.

Он создает выходной файл XML с подробными метриками по методам и сводки сводок для иерархии выше этого (класс, пакет, подсистема). Использование XLST (или awk или perl или ...) Было бы очень легко извлечь метрику, которую вы хотите для полного резюме или для отдельного метода, и проверить свой порог.