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

На работе мы используем несколько инструментов для сбора нескольких показателей (в основном цикломатическая сложность и 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 должны быть расслаблены... и так далее и тому подобное.

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

Спасибо.


person luis.espinal    schedule 27.05.2010    source источник


Ответы (2)


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

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

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

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

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

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

person matt b    schedule 27.05.2010
comment
Плохо, под компиляцией я подразумеваю шаг, на котором javac начинает выплевывать байт-код. Мы используем проприетарный инструмент на работе, который сканирует исходный код Java и извлекает из него метрики (компиляция не требуется), но этот инструмент не позволяет сделать его частью процесса сборки. Что касается идеи использования аннотации для добавления заданного порога, то это более или менее результат процесса. Сборка прерывается, если класс имеет метод с цикломатической сложностью выше, скажем, 10, за исключением задокументированных случаев, которые представлены, рассмотрены и приняты (и, таким образом, аннотированы таким образом для продолжения сборки). - person luis.espinal; 28.05.2010

Инструмент SD Java Metrics вычисляет большинство основных показателей (не LCOM, но, безусловно, цикломатическая сложность). ) и запускается из командной строки.

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

person Ira Baxter    schedule 04.06.2010
comment
Интересный! Большое тебе спасибо! - person luis.espinal; 06.06.2010