Инструменты анализа сложности кода вне циклической сложности

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

Какие еще инструменты доступны для идентификации проблемного кода Java?

Обратите внимание: мы уже используем PMD и FindBugs, которые, как я считаю, отлично подходят для идентификации уровня метода.

Ответ 1

Мой опыт заключается в том, что наиболее важными показателями при проверке работоспособности кода являются:

Cyclomatic Complexity, чтобы идентифицировать большие куски кода, которые, вероятно, трудно понять/изменить.
Глубина вложенности, чтобы найти похожие точки (высокая глубина вложенности автоматически выше CC, но не обязательно наоборот, так что оценка на обоих важна для просмотра).
Включение/выключение вентилятора, чтобы лучше понять отношения между методами/классами и реальную важность отдельных методов.

При изучении кода, написанного другими, часто бывает полезно включать динамические методы. Просто запустите общие сценарии использования с помощью инструмента покрытия профиля/кода, чтобы обнаружить:

Кодекс, который на самом деле выполняется много (профилировщик отлично подходит для этого, просто игнорируйте информацию о времени и посмотрите на количество попаданий).
Покрытие кода отлично подходит для поиска (почти) мертвого кода. Чтобы вы не инвестировали время в код рефакторинга, который редко выполняется в любом случае.

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

Ответ 2

Google Testability Explorer проверяет, например, на синглтоны и другие статические вещи, которые являются плохими запахами в дизайне. Metrics - это плагин Eclipse, который измеряет почти все показатели кода, известные человечеству. Я использовал и могу легко рекомендовать оба.

Ответ 3

Sonar пытается идентифицировать "горячие точки" сложности и ремонтопригодности, сочетая результаты различных инструментов с открытым исходным кодом (включая PMD и Findbugs). Он хорошо интегрируется с серверами Maven и CI (особенно с Hudson).

ИЗМЕНИТЬ с помощью extraneon

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

Здесь объясняется метрика.

Ответ 4

Я никогда не использовал его, но я нашел это довольно интересным и обещающим:

http://erik.doernenburg.com/2008/11/how-toxic-is-your-code/

И я использовал этот и нашел его чрезвычайно полезным, потому что хорошая визуализация зависимостей

http://www.headwaysoftware.com/products/structure101/index.php

Ответ 5

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

Emma обеспечивает анализ охвата кода, хотя это действительно для тестирования.

Ответ 6

Инструмент NDepend для кода .NET позволит вам проанализировать многие аспекты сложности кода, включая такие кодовые метрики, как: Цикломатическая сложность, глубина гнездования, отсутствие сцепления методов, охват тестами...

... включая анализ зависимостей и в том числе Правила кода над запросами LINQ (CQLinq), посвященные спросу, что сложно в моем коде, и написать правило. Вокруг 200 правил кода по умолчанию. Они касаются анти-шаблонов, таких как Singleton, обнаружение threading проблемы, обнаружение проблем связи, таких как Уровень пользовательского интерфейса не должен использовать непосредственно типы DB...

A назад, я написал статью, чтобы суммировать несколько аспектов сложности кода: Борьба с сложной сложностью