Checkstyle против PMD


86

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

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

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

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

Ответы:


71

Вам обязательно стоит использовать FindBugs . По моему опыту, количество ложных срабатываний очень низкое, и даже наименее критические предупреждения, о которых он сообщает, в определенной степени заслуживают внимания.

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


49
+1 за добавление вашей рекомендации FindBugs. Однако я категорически не согласен с вашим мнением о Checkstyle, если вы не разработчик-одиночка со своим собственным идиосинкразическим стилем. Для команд согласование общего разумного подмножества правил и последующее использование автоматизированного инструмента, такого как Checkstyle, для их автоматического применения приводит к созданию кода, доступного для чтения всем.
Джон Тоблер

1
Хотя FindBugs и не идеален, он, безусловно, лучший. PMD и checkstyle указывают на откровенно плохие практики. Избегать любой ценой, если вы не очень хорошо знаете, какие предупреждения действительны, а какие нет.
DPM

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

38

Оба программного обеспечения полезны. Checkstyle поможет вам во время программирования, проверив ваш стиль кодирования, то есть фигурные скобки, именование и т. Д. Простые вещи, но их очень много!

PMD поможет вам, проверив более сложные правила, например, во время проектирования ваших классов, или для более особых проблем, таких как правильная реализация функции клонирования. Просто PMD проверит ваш стиль программирования

Однако оба программного обеспечения страдают от схожих правил, которые иногда плохо объясняются. При плохой конфигурации вы можете проверить два или два раза противоположные вещи, например, «Удалить бесполезные конструкторы» и «Всегда один конструктор».


10
В яблочко. ИМХО, это два инструмента, нацеленных на разные вещи, поэтому я не уверен, что они вообще сопоставимы. Если вы хотите внедрить стандартный стиль кодирования в команде разработчиков, используйте Checkstyle. Если вы хотите проанализировать код на предмет проблем проектирования или неправильных методов кодирования, используйте PMD.
aberrant80

24

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

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

Тип соглашения (Checkstyle) - это клей, который позволяет людям работать вместе и высвобождать творческий потенциал вместо того, чтобы тратить время и силы на понимание несовместимого кода.

Примеры стиля проверки:

  • Есть ли javadoc для общедоступных методов?
  • Соответствует ли проект соглашениям Sun об именах?
  • Написан ли код в едином формате?

в то время как PMD напоминает вам плохие практики:

  • Перехват исключения без каких-либо действий
  • Имея мертвый код
  • Слишком много сложных методов
  • Прямое использование реализаций вместо интерфейсов
  • Реализация метода hashcode () без метода not equals (Object object)

источник: http://www.sonarsource.org/what-makes-checkstyle-pmd-findbugs-and-macker-complementary/


1
Я согласен с тем, что Checkstyle больше внимания уделяет формату кода и заставляет разработчика следовать «Стандарту кода», но он также может обнаруживать множество плохих практик, посмотрите здесь , а расширение Checkstyle проще для разработки, но я согласен что он имеет ограничения и никогда не преодолеет PMD и FindBug.
Роман Иванов

15

Мы используем оба:

  • Проверьте стиль, чтобы убедиться, что все в команде пишут код одинаковым образом.
  • PMD для поиска проблемных областей кода и следующих целей рефакторинга

7

Если ваше основное место использования - во время разработки в eclipse, то CodePro из Instantiations будет лучшим вариантом. Раньше это был коммерческий инструмент, но теперь Google купил Instantiations, так что теперь CodePro analytix бесплатен.

Посетите http://code.google.com/javadevtools/download-codepro.html


7

Если вы просмотрели списки правил Checkstyle, PMD и Findbugs, то увидели, что все три предоставляют ценный результат, и все три в некоторой степени перекрываются, а также вносят в таблицу свои собственные уникальные правила. Вот почему такие инструменты, как Sonar, используют все три.

Тем не менее, Findbugs имеет самые специфические или нишевые правила (например, «Сомнительный отлов IllegalMonitorStateException» - как часто вы можете столкнуться с этим?), Поэтому его можно использовать с небольшой конфигурацией или без нее, и к его предупреждениям следует относиться серьезно. В Checkstyle и PMD правила являются более общими и связаны со стилем, поэтому их следует использовать только с пользовательскими файлами конфигурации, чтобы уберечь команду от лавины нерелевантной обратной связи («Tab char в строке 5», «Tab char в строке 6», "Tab char в строке 7" ... вы понимаете). Они также предоставляют мощные инструменты для написания ваших собственных расширенных правил, например, правило Checkstyle DescendentToken .

При использовании всех трех (особенно с таким инструментом, как Sonar) все они должны быть настроены отдельно (требуется как минимум несколько дней, чтобы охватить все правила), обращая внимание на предотвращение дублирования (все три инструмента обнаруживают, что hashCode () был overridden и equals () нет, например).

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


6

Sonar (http://www.sonarsource.org/) - очень полезная открытая платформа для управления качеством кода, включающая Checkstyle, PMD, Findbugs и многое другое.

Это также указывает на то, что все 3 инструмента имеют право на существование ...


5

Оба инструмента настраиваются и могут делать примерно одно и то же. Тем не менее, если мы говорим о готовых вещах, есть много совпадений, но есть и отдельные правила / проверки. Например, Checkstyle имеет более сильную поддержку проверки Javadoc и поиска магических чисел, чтобы назвать пару. Кроме того, Checkstyle имеет функцию «контроля импорта», которая похожа на функциональность Macker (я не использовал Macker).

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

Также учтите, что если вы решите, что функция «контроль импорта» Checkstyle охватывает то, что вы хотели от Macker, то вы можете реализовать PMD / Checkstyle вместо PMD / Macker. В любом случае это два инструмента, но с Checkstyle вы получите то, что PMD не делает из коробки, «бесплатно».


5

Checkstyle и PMD хорошо проверяют стандарты кодирования и их легко расширить. Но PMD имеет дополнительные правила для проверки цикломатической сложности, сложности Npath и т. Д., Что позволяет писать здоровый код.

Еще одним преимуществом использования PMD является CPD (детектор копирования / вставки). Он обнаруживает дублирование кода в проектах и ​​не ограничивается JAVA. Он работает и для JSP. У Нила Форда есть хорошая презентация по гибкой разработке , основанной на метриках , в которой рассказывается о многих инструментах, полезных для разработки на Java / Java EE.


4
Для тех, кто читает это ... теперь у checkstyle есть эти checkstyle.sourceforge.net/config_metrics.html checkstyle.sourceforge.net/config_duplicates.html
smp7d

4

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

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


4

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

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

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

Шаги:

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

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


К вашему сведению, SpotBugs является «духовным наследником FindBugs» , и документация SpotBugs довольно хороша. Насколько мне известно, FindBugs не обновлялся годами.
скомиса

Никогда не слышал о SpotBugs, вероятно потому, что FindBugs + fbcontrib было достаточно на долгое время, приятно знать, что есть замена
Кристоф Русси

Здесь обсуждается это здесь: news.ycombinator.com/item?id=12885549
Кристоф Русси

Также стоит отметить, что инструменты, как правило, имеют настраиваемую чувствительность. Например, когда вы начинаете с FindBugs / SpotBugs, вам может потребоваться выбрать Высокий порог, чтобы отловить только самые серьезные ошибки, а затем понизить порог по мере исправления ошибок.
ThrawnCA

@ThrawnCA да, но даже с учетом чувствительности: в большом проекте будет обнаружено, что слишком много ошибок будет исправлено в разумные сроки. Вместо этого я добавляю по одному правилу за раз, начиная с самых низких «висящих» плодов, таких как потенциальное обнаружение NP, а затем перехожу к таким правилам, как незакрытые ресурсы.
Christophe Roussy

3

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

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

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

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

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

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


1
Есть также способы интегрировать его в сборку и заставить его выйти из строя при нарушении (например, с помощью maven). Я сделал это для Checkstyle, PMD и FindBugs. Как вы сказали, отчетности недостаточно.
Christophe Roussy

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>

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

Мы думаем так же, но чтобы это исправить, мне нужно, чтобы это было выделено в моем коде или что-то подобное. По крайней мере, ты settings.jarпомог.
Адам Арольд

2

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


1

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


2
Верно в 2008 году, но сегодня Checkstyle набрал большую скорость.
barfuin

1

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


-2

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


В чекстиле есть одна хорошая особенность: он допускает какое-то гибкое правило, такое как RegexpSingleline ...
Джигар Шах
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.