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

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

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

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

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

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

12 108
javascript code-coverage static-analysis

12 ответов:

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

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

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

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

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

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

/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.

мои преобразования формата предупреждения выполняются моим муравьем скрипт с Муравьем 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 " позволяет легко запустить простой поиск, чтобы найти все экземпляры для всех инструментов по всей базе кода.

66

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

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

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

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

16

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

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

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

  • JDepend
  • Tag checker (TODO, FIXME и т. д.)

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

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

11

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

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

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

8

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

4

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

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

3

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

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

1

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

1

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

1

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

1

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

1

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

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

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

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

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

0