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

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

Чи є користь від використання обох? Я не хочу підтримувати 2 інструменти, якщо один буде працювати. Якщо ми обираємо одну, яку з них слід використовувати і чому?

Ми також плануємо використовувати FindBugs. Чи існують інші засоби статичного аналізу, на які слід звернути увагу?

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

Вам обов’язково слід використовувати FindBugs . На моєму досвіді, показник хибнопозитивних показників є дуже низьким, і навіть найменш критичні попередження, про які він повідомляє, до певної міри заслуговують на увагу.

Що стосується Checkstyle проти PMD, я б не використовував Checkstyle, оскільки це стосується лише стилю. З мого досвіду, Checkstyle буде повідомляти про безліч речей, які абсолютно не мають значення. З іншого боку, PMD також може вказувати на сумнівні практики кодування, і його результати, як правило, є більш актуальними та корисними.

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

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

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

Якщо ми обираємо одну, яку з них слід використовувати і чому?

Ці інструменти не конкурують, але доповнюють один одного і повинні використовуватися одночасно.

Конвенційний тип (Checkstyle) - це клей, який дозволяє людям працювати разом і звільнити свою творчість, замість того щоб витрачати час і енергію на розуміння непослідовного коду.

Приклади контрольного стилю:

• Чи існує javadoc на публічних методах?
• Чи проект дотримується конвенцій щодо іменування сонця?
• Чи написаний код у незмінному форматі?

в той час як PMD нагадує вам погані практики:

• Ловіть виняток, не роблячи нічого
• Маючи мертвий код
• Забагато складних методів
• Безпосереднє використання реалізацій замість інтерфейсів
• Реалізація методу hashcode () без методу not equals (Object object)

джерело: http://www.sonarsource.org/what-makes-checkstyle-pmd-findbugs-and-macker-complementary/

Ми використовуємо обидва:

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

Якщо ваше основне місце використання знаходиться під час розробки в затемненні, найкращим буде CodePro від Instantiations. Раніше це був комерційний інструмент, але зараз Google придбав Instantiations, тому CodePro analytix зараз безкоштовний.

Перегляньте сторінку http://code.google.com/javadevtools/download-codepro.html

Якщо ви ознайомилися зі списками правил Checkstyle, PMD та Findbugs, ви побачили, що всі три забезпечують цінний результат, і всі три до певної міри збігаються, а також вносять свої, унікальні правила до таблиці. Ось чому такі інструменти, як Sonar, використовують усі три.

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

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

Підводячи підсумок, якщо ви вважаєте статичний аналіз коду цінним, відхиляти значення, яке надає будь-яке з трьох, не має сенсу, але щоб використовувати всі три, вам доведеться витратити час, щоб налаштувати їх, щоб дати вам корисний відгук.

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 Development

Я вважаю, що 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 означає, що розробник повинен свідомо вирішити запустити звіт. Тоді як порушення правил чек-стилу автоматично повідомляються їм по мірі їх розвитку. Хоча PMD і містить більш широкий набір правил, на мою думку, автоматичне попередження / повідомлення про порушення в IDE вартує клопоту з підтримкою 2 наборів правил.

Отже, для будь-яких проектів, над якими я працюю, ми використовуємо обидва інструменти: Checkstyle, що застосовується в IDE, PMD повідомляється в IDE, і обидва звітуються і вимірюються в збірках (через Jenkins).

Погляньте на плагін qulice-maven, який поєднує в собі 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 - це те, про що люди мали на увазі 4 роки тому, але я вважаю, що PMD підтримується більш постійно і з якими іншими середовищами розробки / плагінами обирають працювати.

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

PMD - найкращий інструмент у порівнянні з контрольним стилем. Checkstyles може не мати можливості аналізувати код, тоді як PMD пропонує безліч функцій для цього! Offcourse PMD не опублікував правила щодо javadoc, коментарів, відступів тощо. І, до речі, я планую впровадити ці правила ....... дякую