Checkstyle vs. PMD - PullRequest
       76

Checkstyle vs. PMD

82 голосов
/ 08 октября 2008

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

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

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

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

Ответы [ 17 ]

65 голосов
/ 09 октября 2008

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

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

36 голосов
/ 09 октября 2008

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

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

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

22 голосов
/ 06 сентября 2011

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

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

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

Примеры Checkstyle:

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

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

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

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

13 голосов
/ 09 октября 2008

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

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

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

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

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

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

7 голосов
/ 18 ноября 2010

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

Выезд http://code.google.com/javadevtools/download-codepro.html

6 голосов
/ 25 июня 2011

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

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

5 голосов
/ 20 февраля 2009

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

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

4 голосов
/ 14 октября 2008

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

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

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

4 голосов
/ 09 октября 2008

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

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

...