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

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

1 голос
/ 27 мая 2010

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

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

Спасибо.

Ответы [ 2 ]

4 голосов
/ 27 мая 2010

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

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

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

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

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

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

1 голос
/ 04 июня 2010

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

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

...