Checkstyle и PMD и

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

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

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

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

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

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

Checkstyle примеры:

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

пока ПМД напоминает плохой практики:

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

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

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

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

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

проверить http://code.google.com/javadevtools/download-codepro.html

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

посмотри 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>

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

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

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

действия:

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

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

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

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

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

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