Які інструменти аналізу коду ви використовуєте для своїх проектів Java? [зачинено]

Які інструменти аналізу коду ви використовуєте у своїх проектах Java?

Мене цікавлять усі види

• інструменти аналізу статичного коду (FindBugs, PMD та будь-які інші)
• інструменти покриття коду (Cobertura, Emma та будь-які інші)
• будь-які інші інструментальні засоби
• що-небудь інше, якщо я щось пропускаю

Якщо можливо, також вкажіть, які інструменти побудови ви використовуєте та як добре ці інструменти інтегруються як з вашими IDE, так і з інструментами побудови.

Якщо інструмент доступний лише певним чином (як плагін IDE або, скажімо, плагін інструменту збирання), цю інформацію також варто зазначити.

Для інструментів статичного аналізу я часто використовую CPD, PMD , FindBugs та Checkstyle .

CPD - це інструмент "Детектор копіювання / вставки" PMD. Я використовував PMD деякий час, перш ніж помітив посилання "Пошук дублюючого коду" на веб-сторінці PMD .

Я хотів би зазначити, що іноді ці інструменти можуть бути розширені за межами набору правил "поза коробкою". І не лише тому, що вони з відкритим кодом, щоб ви могли їх переписати. Деякі з цих інструментів поставляються із додатками чи "гачками", які дозволяють розширити їх. Наприклад, PMD поставляється з інструментом "конструктор", який дозволяє створювати нові правила. Також Checkstyle має перевірку DescendantToken, яка має властивості, що дозволяють істотно налаштувати.

Я інтегрую ці інструменти у збірку на основі мурашок . Ви можете перейти за посиланням, щоб побачити мою коментовану конфігурацію.

Окрім простої інтеграції в збірку, мені здається корисним налаштувати інструменти, щоб дещо «інтегруватися» в пару інших способів. А саме, повідомляти про рівномірність генерації та попередження попередження. Я хотів би додати ці аспекти до цієї дискусії (яка, мабуть, має також тег "статичний аналіз"): як люди налаштовують ці інструменти для створення "уніфікованого" рішення? (Я задав це питання окремо тут )

По-перше, для попереджувальних звітів я перетворюю вихід, щоб кожне попередження мало простий формат:

/absolute-path/filename:line-number:column-number: warning(tool-name): message

Це часто називається "формат Emacs", але навіть якщо ви не використовуєте Emacs, це розумний формат для гомогенізації звітів. Наприклад:

/project/src/com/example/Foo.java:425:9: warning(Checkstyle):Missing a Javadoc comment.

Мої перетворення формату попередження виконуються моїм сценарієм Ant з фільтром Ant .

Друга «інтеграція», яку я роблю, - це попередження придушення. За замовчуванням кожен інструмент підтримує коментарі або примітку (або обидва), які ви можете помістити у свій код, щоб заглушити попередження, яке ви хочете ігнорувати. Але ці різні запити щодо придушення попередження не мають послідовного вигляду, який здається дещо дурним. Коли ви придушуєте попередження, ви придушуєте попередження, то чому б не завжди писати " SuppressWarning?"

Наприклад, конфігурація за замовчуванням PMD пригнічує генерацію попереджень у рядках коду з рядком " NOPMD" в коментарі. Також PMD підтримує @SuppressWarningsанотацію Java . Я налаштовую PMD використовувати коментарі, що містять " SuppressWarning(PMD." замість того, NOPMDщоб придушення PMD виглядали однаково. Я заповнюю конкретне правило, яке порушується при використанні придушення стилю коментарів:

// SuppressWarnings(PMD.PreserveStackTrace) justification: (false positive) exceptions are chained

Тільки SuppressWarnings(PMD.частина " " є важливою для коментаря, але вона відповідає підтримці PMD для @SuppressWarningпримітки, яка розпізнає окремі порушення правил за назвою:

@SuppressWarnings("PMD.CompareObjectsWithEquals") // justification: identity comparision intended

Аналогічно, Checkstyle пригнічує генерацію попереджень між парами коментарів (не підтримується анотація). За замовчуванням коментарі для вимкнення та ввімкнення Checkstyle містять рядки CHECKSTYLE:OFFта CHECKSTYLE:ONвідповідно. Зміна цієї конфігурації (за допомогою "SuppressionCommentFilter" Checkstyle) для використання рядків " BEGIN SuppressWarnings(CheckStyle." і " END SuppressWarnings(CheckStyle." робить елементи управління схожішими на PMD:

// BEGIN SuppressWarnings(Checkstyle.HiddenField) justification: "Effective Java," 2nd ed., Bloch, Item 2
// END SuppressWarnings(Checkstyle.HiddenField)

Що стосується коментарів Checkstyle, то особливе порушення перевірки ( HiddenField) є суттєвим, оскільки кожна перевірка має власну " BEGIN/END" пару коментарів.

FindBugs також підтримує придушення покоління попередження з @SuppressWarningsанотацією, тому не потрібно додаткової конфігурації для досягнення певного рівня однаковості з іншими інструментами. На жаль, Findbugs повинен підтримувати користувацьку @SuppressWarningsанотацію, оскільки вбудована @SuppressWarningsанотація на Java має SOURCEполітику збереження, яка недостатньо сильна, щоб зберегти примітку у файлі класу, де її потребує FindBugs. Я повністю кваліфікуюча подання попереджень FindBugs, щоб уникнути зіткнення з @SuppressWarningsанотацією Java :

@edu.umd.cs.findbugs.annotations.SuppressWarnings("UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR")

Ці методи дозволяють речі виглядати досить послідовно в різних інструментах. Зауважте, що наявність кожного придушення попередження містить рядок " SuppressWarnings" дозволяє легко запустити простий пошук, щоб знайти всі екземпляри всіх інструментів протягом усієї бази коду.

Я використовую комбінацію Cobertura, Checkstyle, (Ecl) Emma та Findbugs.

EclEmma - дивовижний плагін Eclipse, який показує покриття коду, забарвлюючи джерело java в редакторі ( скріншот ) - покриття створюється за допомогою тесту JUnit. Це дійсно корисно, коли ви намагаєтесь з’ясувати, які рядки охоплені у певному класі, або якщо ви хочете побачити, які саме рядки охоплені одним тестом. Це набагато зручніше для користувачів та корисніше, ніж створювати звіт, а потім переглядати звіт, щоб побачити, які класи мають низький ступінь охоплення.

Плагіни Checkstyle та Findbugs Eclipse також корисні, вони створюють попередження в редакторі під час введення.

Maven2 має додатки для звітів, які працюють з вищезазначеними інструментами для створення звітів під час збирання. Ми використовуємо це для отримання загальних звітів про проекти, які є більш корисними, коли потрібно сукупні числа. Вони генеруються нашими збірками CI, які працюють за допомогою континууму .

Всі наведені нижче ми використовуємо та інтегруємо easiy як у наші версії Maven 2.x, так і у Eclipse / RAD 7:

• Тестування - JUnit / TestNG
• Аналіз коду - FindBugs, PMD
• Кодове покриття - конюшина

Крім того, у нашому Maven build:

• JDepend
• Перевірка тегів (TODO, FIXME тощо)

Крім того, якщо ви використовуєте Maven 2.x, CodeHaus має колекцію зручних плагінів Maven у своєму проекті Mojo .

Примітка: Clover має нестандартну інтеграцію з сервером Bamboo CI (оскільки вони обидва продукти Atlassian). Також є плагіни Bamboo для FindBugs, PMD і CheckStyle, але, як зазначалося, у них є і безкоштовний сервер Hudson CI.

Я використовую статичний аналіз, вбудований в IntelliJ IDEA. Ідеальна інтеграція.

Я використовую кодове покриття, вбудоване в Intellij IDEA (на основі EMMA). І знову ідеальна інтеграція.

Це інтегроване рішення є надійним, потужним та простим у використанні в порівнянні з інструментами для складання разом різних виробників.

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

Ми використовуємо FindBugs і Checkstyle, а також конюшину для покриття коду.

Я думаю, що важливо провести якийсь статичний аналіз, який підтримує ваш розвиток. На жаль, до цих пір не широко поширено, що ці інструменти є важливими.

Ми використовуємо FindBugs та JDepend інтегровані з Ant. Ми використовуємо JUnit, але не використовуємо жодного інструменту покриття.

Я не використовую його інтегровано до Rational Application Developer (IDE, який я використовую для розробки програм J2EE), тому що мені подобається, як акуратно це виглядає, коли ви запускаєте javac у консолі Windows. : P

Мені пощастило з Кобертура. Це інструмент покриття коду, який можна виконати за допомогою сценарію мурашника як частину звичайної збірки і може бути інтегрований до Хадсона.

Наша команда використовує PMD та Cobertura, насправді наші проекти - це основні проекти, і включити модулі для аналізу коду дуже просто. Справжнє питання стосується конкретного проекту, аналіз якого потрібно використовувати, на мою думку, ви не можете використовувати однакові плагіни для кожного проекту.

у нашому проекті ми використовуємо Sonar перед контрольним стилем, pmd .... спільно з CI (Bamboo, Hudson) ми також отримуємо хорошу історію нашої якості джерела та те, що ми направляємо. Мені подобається Sonar, тому що ви один центральний інструмент в CI Stack, який робить це для вас, і ви можете легко налаштувати правила для кожного проекту.

Структура 101 добре аналізує код і знаходить залежності циклічного пакету.

Я шукаю багато відповідей, щоб дізнатися про нові інструменти та закріпити ці знання в одному питанні / темі, тому сумніваюся, що на це питання буде 1 правдива відповідь.

Моя відповідь на моє власне питання полягає в тому, що ми використовуємо:

• Findbugs шукати поширені помилки погано / кодування - запустіть з Maven, а також легко інтегрується в Eclipse
• Кобертура для наших звітів про висвітлення - працює від Мейвена

Hudson також має плагін для сканування завдань, який відображатиме кількість ваших TODO та FIXME, а також показує, де вони знаходяться у вихідних файлах.

Всі вони інтегровані з Maven 1.x у нашому випадку та прив’язані до Хадсона, який здійснює наші надходження на реєстрацію, а також додаткові речі щоночі та щотижня. Графіки тенденцій Хадсона показують наші тести JUnit, покриття, пошукові помилки, а також відкриті завдання. Існує також плагін Хадсон, який звітує та графікує наші попередження про компіляцію. У нас також є кілька тестів на працездатність із власними графіками продуктивності та використання пам’яті з часом, використовуючи також плагін Hudson сюжети.