Checkstyle vs. PMD

Question

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

Есть ли польза от использования обоих? Я не хочу поддерживать 2 инструмента, если один будет работать. Если мы выберем тот, который мы должны использовать и почему?

Мы также планируем использовать FindBugs. Есть ли другие инструменты статического анализа, на которые мы должны обратить внимание?

Обновление: Похоже, консенсус заключается в том, что PMD предпочтительнее, чем CheckStyle. Я не вижу веской причины использовать оба, и я не хочу поддерживать 2 набора файлов правил, поэтому мы, вероятно, будем стремиться исключительно к PMD. Мы также добавим FindBugs и, возможно, в конечном итоге Macker для обеспечения соблюдения архитектурных правил.

Answer 1

Одна вещь, которую я до сих пор не видел, состоит в том, что есть плагины для IDE, которые будут применять наборы правил CheckStyle в вашем коде, тогда как плагины PMD будут сообщать только о нарушениях. Например, в многосайтовом проекте с участием нескольких команд программистов важно активно применять стандарты, а не просто сообщать о них.

Оба инструмента имеют плагины, доступные для IntelliJ, NetBeans и Eclipse (на мой взгляд, это охватывает большую часть использования). Я не так хорошо знаком с NetBeans, поэтому могу комментировать только IntelliJ и Eclipse.

В любом случае плагины PMD для IntelliJ и Eclipse будут генерировать отчеты по требованию о нарушениях PMD в кодовой базе проекта.

Плагины CheckStyle, с другой стороны, будут подсвечивать нарушения на лету и могут (по крайней мере для IntelliJ, у меня меньше опыта работы с Eclipse) настраиваться на автоматическое преобразование некоторых проблем (например, для 'OneStatementPerLine'). CR-LF между операторами, для 'NeedBraces', добавит фигурные скобки там, где они отсутствуют и т. Д.). Очевидно, что автоматически могут быть исправлены только более простые нарушения, но это все же помогает в устаревших проектах или проектах, расположенных в нескольких местах.

«По запросу» для PMD означает, что разработчик должен сознательно принять решение о запуске отчета. Принимая во внимание, что нарушения Checkstyle автоматически сообщаются им по мере их развития. В то время как PMD содержит более расширенный набор правил, на мой взгляд, автоматическое выявление / сообщение о нарушениях в IDE стоит хлопот в отношении поддержания 2 наборов правил.

Поэтому для любых проектов, над которыми я работаю, мы используем оба инструмента: Checkstyle, применяемый в IDE, PMD, сообщаемый в IDE, и , оба , сообщаемые и измеряемые в сборках (через Jenkins).

Answer 2

и 10 лет спустя ... В 2018 году я использую все из них Checkstyle, PMD и FindBugs.

Начните с FindBugs . Может быть, позже добавлю PMD и Checkstyle.

Никогда не применяйте вслепую правила по умолчанию !

Шаги:

• запустить один инструмент с правилами по умолчанию для проекта, в котором много кода
• адаптируйте правила к этому проекту, закомментируйте бесполезные правила с некоторыми примечаниями
• сосредоточить внимание на правилах низко висящих фруктов (NPE, проверки логгера, незакрытые проверки ресурсов, ...)
• выполнить некоторые исправления для правил, которые вы считаете стоящими (по одному!)
• делайте это для каждого инструмента, но не для всех сразу!
• повторите этот процесс

В идеале каждый проект может иметь отдельные правила. Мне нравится запускать правила через сборку (через плагины maven) и терпеть неудачу при ошибках правил, когда я знаю, что проект проходит все правила, которые я определил. Это заставляет разработчиков принимать меры, потому что отчетов недостаточно . С этого момента ваш проект является в значительной степени пуленепробиваемым, и вы даже можете добавить больше правил позже и / или написать собственные правила.

Answer 3

Взгляните на qulice-maven-plugin , который объединяет вместе Checkstyle, PMD, FindBugs и несколько других статических анализаторов и предварительно конфигурирует их. Прелесть этой комбинации в том, что вам не нужно настраивать их индивидуально в каждом проекте:

<plugin>
  <groupId>com.qulice</groupId>
  <artifactId>qulice-maven-plugin</artifactId>
  <version>0.15</version>
  <executions>
    <execution>
      <goals>
        <goal>check</goal>
      </goals>
    </execution>
  </executions>
</plugin>

Answer 4

Я бы повторил, что PMD является более современным продуктом для проверки стиля / соглашения Java. Что касается FindBugs, многие коммерческие группы разработчиков используют Coverity.

Answer 5

Я только начал использовать Checkstyle и PMD. На мой взгляд, PMD проще создавать настраиваемые правила для таких вещей, как, если существуют System.gc (), Runtime.gc (), до тех пор, пока вы можете написать запрос XPath, что также совсем не сложно. Тем не менее, PMD не показал мне, что он имеет функцию, чтобы показать номер столбца. Так что для таких вещей, как проверить ограничения столбцов. Возможно, вы захотите использовать Checkstyle.

Answer 6

PMD - лучший инструмент по сравнению с контрольными стилями. Контрольные стили могут не иметь возможности анализировать код, в то время как PMD предлагает множество возможностей для этого! Offcourse PMD не выпустил правила для javadoc, комментариев, отступов и т. Д. И, кстати, я планирую реализовать эти правила ....... спасибо

Answer 7

PMD - это то, на что я нахожу больше людей. Чекстайл был тем, на что люди ссылались 4 года назад, но я считаю, что PMD поддерживается более непрерывно, и с какими другими IDE / плагинами решили работать.