Чекстайл против.ПМД

https://stackoverflow.com/questions/184563

06-07-2019
|

Вопрос

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

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

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

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

Решение

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

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

Другие советы

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

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

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

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

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

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

Примеры контрольных стилей:

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

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

Перехват исключения, ничего не делая
Наличие мертвого кода
Слишком много сложных методов
Прямое использование реализаций вместо интерфейсов
Реализация метода hashcode() без метода notquals(объект 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»). ; " Символ табуляции в строке 7 " ... Вы получите изображение). Они также предоставляют мощные инструменты для написания ваших собственных расширенных правил, например, правило DescendentToken Checkstyle.

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

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

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 не может делать «из коробки» бесплатно ».

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

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

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

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

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

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

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

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

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

Шаги:

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow