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

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

Меня интересуют все виды

  • инструменты статического анализа кода (FindBugs, PMD и любые другие)
  • инструменты покрытия кода (Cobertura, Emma и любые другие)
  • любые другие инструментальные средства
  • что-нибудь еще, если я что-то упускаю

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

Если инструмент доступен только определенным образом (как плагин IDE или, скажем, плагин инструмента сборки), эту информацию также стоит отметить.

Ответов (12)

Решение

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

CPD - это инструмент PMD «Детектор копирования / вставки». Некоторое время я использовал PMD, прежде чем заметил ссылку «Поиск повторяющегося кода» на веб-странице PMD .

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

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

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

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

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

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

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

Мои преобразования формата предупреждений выполняются моим сценарием Ant с цепочками фильтров Ant .

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

Например, конфигурация PMD по умолчанию подавляет создание предупреждений в строках кода со строкой « NOPMD » в комментарии. Кроме того, PMD поддерживает @SuppressWarnings аннотации Java . Я настраиваю 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, соответственно. Изменение этой конфигурации (с помощью «SuppressionCommentFilter» Checkstyle) для использования строк « 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 аннотацию, потому что встроенная @SuppressWarnings аннотация Java имеет SOURCE политику хранения, которая недостаточно сильна, чтобы сохранить аннотацию в файле класса, где она нужна FindBugs. Я полностью квалифицирую подавление предупреждений FindBugs, чтобы избежать конфликтов с @SuppressWarnings аннотацией Java :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • JDepend
  • Проверка тегов (TODO, FIXME и т. Д.)

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

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

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

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

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

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

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

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

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

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

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

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

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