Checkstyle против PMD

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаги:

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

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

Один момент, который я пока не видел, заключается в том, что есть плагины для 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).

Взгляните на 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>

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

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

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

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