Checkstyle против PMD

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Примеры контрольных образцов:

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

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

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

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

Ответ 4

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

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

Ответ 5

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

Отъезд http://code.google.com/javadevtools/download-codepro.html

Ответ 6

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

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

Ответ 7

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

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

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

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

Ответ 8

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

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

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

Ответ 9

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

Другим преимуществом использования PMD является CPD (Copy/Paste Detector). Он обнаруживает дублирование кода по проектам и не ограничивается JAVA. Он также работает для JSP. Neal Ford имеет хорошую презентацию на Metrics Driven Agile Development, в котором рассказывается о многих инструментах, которые полезны для разработки Java/Java EE

Ответ 10

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

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

Ответ 11

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

Ответ 12

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

Ответ 13

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

Ответ 14

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

Ответ 15

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

Ответ 16

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