Какие инструменты анализа кода вы используете для своих проектов Java?

Ответ 1

Для инструментов статического анализа я часто использую CPD, PMD, FindBugs и Checkstyle.

CPD - это инструмент PMD "Copy/Paste Detector". Я некоторое время использовал PMD, прежде чем заметил ссылку "Поиск дублированного кода" на Веб-страница PMD.

Я хотел бы указать, что эти инструменты иногда могут быть расширены за пределами их "готового" набора правил. И не только потому, что они с открытым исходным кодом, так что вы можете их переписать. Некоторые из этих инструментов поставляются с приложениями или "крючками", которые позволяют им быть расширенными. Например, PMD поставляется с "конструктор" , который позволяет создавать новые правила. Кроме того, Checkstyle имеет DescendantToken, который имеет свойства, которые позволяют существенно настроить.

Я интегрирую эти инструменты с конструкцией, основанной на Ant. Вы можете перейти по ссылке, чтобы увидеть мою прокомментированную конфигурацию.

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

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

/absolute-path/filename:line-number:column-number: warning(tool-name): message

Это часто называют "Emacs format", но даже если вы не используете Emacs, это разумный формат для гомогенизации отчетов. Например:

/project/src/com/example/Foo.java:425:9: warning(Checkstyle):Missing a Javadoc comment.

Преобразования формата моего предупреждения выполняются с помощью Ant script с Ant filterchains.

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

Например, конфигурация по умолчанию PMD подавляет генерацию предупреждения в строках кода со строкой "NOPMD" в комментарии. Кроме того, PMD поддерживает аннотацию Java @SuppressWarnings. Я настраиваю PMD для использования комментариев, содержащих "SuppressWarning(PMD." вместо NOPMD, чтобы подавления PMD выглядели одинаково. Я заполняю конкретное правило, которое нарушается при использовании подавления стиля комментариев:

// SuppressWarnings(PMD.PreserveStackTrace) justification: (false positive) exceptions are chained

Только часть "SuppressWarnings(PMD." важна для комментария, но она согласуется с поддержкой PMD для аннотации @SuppressWarning, которая распознает нарушения отдельных правил по имени:

@SuppressWarnings("PMD.CompareObjectsWithEquals") // justification: identity comparision intended

Аналогично, Checkstyle подавляет генерацию предупреждений между парами комментариев (поддержка аннотации не предоставляется). По умолчанию комментарии для включения и выключения Checkstyle содержат строки CHECKSTYLE:OFF и CHECKSTYLE:ON, соответственно. Изменение этой конфигурации (с помощью Checkstyle "SuppressionCommentFilter" ) для использования строк "BEGIN SuppressWarnings(CheckStyle." и "END SuppressWarnings(CheckStyle." делает элементы управления более похожими на PMD:

// BEGIN SuppressWarnings(Checkstyle.HiddenField) justification: "Effective Java," 2nd ed., Bloch, Item 2
// END SuppressWarnings(Checkstyle.HiddenField)

С комментариями Checkstyle особое нарушение проверки (HiddenField) является значительным, поскольку каждая проверка имеет свою собственную пару комментариев "BEGIN/END".

FindBugs также поддерживает подавление генерации предупреждений с аннотацией @SuppressWarnings, поэтому для достижения некоторого уровня единообразия с другими инструментами не требуется дополнительной настройки. К сожалению, Findbugs должен поддерживать пользовательскую аннотацию @SuppressWarnings, потому что встроенная аннотация Java @SuppressWarnings имеет политику хранения SOURCE, которая недостаточно сильна, чтобы сохранить аннотацию в файле класса, в котором нуждается FindBugs. Я полностью квалифицирую подавление предупреждений FindBugs, чтобы избежать столкновения с аннотацией Java @SuppressWarnings:

@edu.umd.cs.findbugs.annotations.SuppressWarnings("UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR")

Эти методы делают вещи разумно согласованными между инструментами. Обратите внимание, что при каждом предупреждении предупреждения строка "SuppressWarnings" упрощает запуск простого поиска, чтобы найти все экземпляры для всех инструментов по всей базе кода.

Ответ 2

Я использую комбинацию Cobertura, Checkstyle, (Ecl) Emma и Findbugs.

EclEmma - это потрясающий плагин Eclipse, который показывает покрытие кода, окрашивая источник java в редакторе (screenshot) - охват генерируется путем запуска теста JUnit. Это действительно полезно, когда вы пытаетесь выяснить, какие строки покрываются в определенном классе, или если вы хотите увидеть, какие строки покрываются одним тестом. Это гораздо удобнее и удобнее, чем генерировать отчет, а затем просматривает отчет, чтобы узнать, какие классы имеют низкий охват.

Плагины Checkstyle и Findbugs Eclipse также полезны, они генерируют предупреждения в редакторе по мере ввода.

В Maven2 есть плагины отчетов, которые работают с вышеуказанными инструментами для создания отчетов во время сборки. Мы используем это для получения общих отчетов по проектам, которые более полезны, если вы хотите, чтобы суммарные числа. Они генерируются нашими сборками CI, которые выполняются с помощью Continuum.

Ответ 3

Все последующие мы используем и интегрируем easiy как в наших сборках Maven 2.x, так и в Eclipse/RAD 7:

• Тестирование - JUnit/TestNG
• Анализ кода - FindBugs, PMD
• Покрытие кода - Clover

Кроме того, в наших сборках Maven мы имеем:

• JDepend
• Контроллер тегов (TODO, FIXME и т.д.)

Кроме того, если вы используете Maven 2.x, CodeHaus имеет набор удобных плагинов Maven в своем проекте Mojo.

Примечание. У клевера есть встроенная интеграция с Bamboo CI-сервером (поскольку они оба являются продуктами Atlassian). Существуют также плагины Bamboo для FindBugs, PMD и CheckStyle, но, как уже отмечалось, у этого бесплатного сервера Hudson CI тоже есть.

Ответ 4

Я использую статический анализ, встроенный в IntelliJ IDEA. Идеальная интеграция.

Я использую покрытие кода, встроенное в Intellij IDEA (на основе EMMA). Опять же, идеальная интеграция.

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

Ответ 5

Checkstyle - это еще один, который я использовал в предыдущей компании... в основном для проверки стиля, но он может сделать некоторый статический анализ тоже. Кроме того, Clover для покрытия кода, хотя имейте в виду, что это не бесплатный инструмент.

Ответ 6

Мы используем FindBugs и Checkstyle, а также Clover для покрытия кода.

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

Ответ 7

Мы используем FindBugs и JDepend, интегрированные с Ant. Мы используем JUnit, но мы не используем инструмент покрытия.

Я не использую его, интегрированный в Rational Application Developer (IDE, который я использую для разработки приложений J2EE), потому что мне нравится, насколько он выглядит аккуратно, когда вы запускаете javac на консоли Windows.: P

Ответ 8

Мне повезло с Кобертурой. Это инструмент для покрытия кода, который можно выполнить с помощью ant script как часть вашей обычной сборки и может быть интегрирован в Hudson.

Ответ 9

Наша команда использует PMD и Cobertura, на самом деле наши проекты - проекты maven, и очень просто включить плагины для анализа кода. Реальный вопрос был бы для конкретного проекта, анализ которого вы должны использовать, я считаю, что вы не могли использовать одни и те же плагины для каждого проекта.

Ответ 10

в нашем проекте мы используем Sonar перед checkstyle, pmd.... вместе с CI (Bamboo, Hudson), мы получаем также хорошую историю нашего качества источника и то, что мы направляем. Мне нравится Sonar, потому что вы один центральный инструмент в CI Stack, который делает это для вас, и вы можете легко настраивать правила для каждого проекта.

Ответ 11

Структура 101 хороша при анализе кода и поиске зависимостей циклического пакета.

Ответ 12

Я ищу много ответов, чтобы узнать о новых инструментах и ​​объединить эти знания в одном вопросе/потоке, поэтому я сомневаюсь, что на этот вопрос будет 1 верный ответ.

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

• Findbugs для поиска общих ошибок/кодирования - запускается с maven, а также легко интегрируется в Eclipse
• Cobertura для наших отчетов о покрытии - работает от maven

В Hudson также есть плагин-сканер задач, который отображает количество ваших TODO и FIXME, а также показывает, где они находятся в исходных файлах.

Все интегрированы с Maven 1.x в нашем случае и связаны с Hudson, который запускает наши сборки на регистрацию, а также дополнительные вещи в ночное время и в неделю. График Хадсона показывает наши тесты JUnit, покрытие, findbugs, а также открытые задачи. Существует также плагин Hudson, который сообщает и отображает наши предупреждения компиляции. У нас также есть несколько тестов производительности с их собственными графиками производительности и использования памяти с течением времени с использованием плагина сюжета Hudson.