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

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

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

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

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

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

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

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

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

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

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

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

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

Все перечисленное мы используем и легко интегрируем как в наши сборки 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 они тоже есть.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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