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

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

Затем, когда мы запускаем инструмент, по умолчанию применяется строгий (и настраиваемый) метрический порог, за исключением тех артефактов, которые аннотируются с (надеющимся документированным и законным) более расслабленным порогом. Для некоторых методов, которые не могут быть / нельзя уменьшить, имеет смысл расслабленной цикломатической сложности. Для обычного поведения Pojos W / O LCOMS нужно расслабиться ... и так далее и так далее.

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

Спасибо.

Answer 1

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

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

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

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

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

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

Answer 2

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

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