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

Для инструментов статического анализа я часто использую 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 filterchains .

Вторая «интеграция», которую я делаю, предназначена для подавления предупреждений. По умолчанию каждый инструмент поддерживает комментарии или аннотации (или оба), которые вы можете разместить в своем коде, чтобы отключить предупреждение, которое вы хотите игнорировать. Но эти различные запросы на подавление предупреждений не выглядят согласованно, что выглядит несколько глупо. Когда вы подавляете предупреждение, вы подавляете предупреждение, так почему бы не всегда писать « 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 конкретное нарушение check ( 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. :П

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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