Findbugs intellij idea как использовать

Инструменты статического анализа Java в Eclipse и IntelliJ IDEA

В нашем введении в FindBugs мы рассмотрели функциональность FindBugs как инструмента статического анализа и то, как его можно напрямую интегрировать в IDE, такие как Eclipse и IntelliJ Idea.

В этой статье мы рассмотрим несколько альтернативных инструментов статического анализа для Java и их интеграцию с Eclipse и IntelliJ IDEA.

2. ПМД​

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

2.1. Интеграция с Eclipse​

Плагин PMD можно установить напрямую из Eclipse Marketplace. Плагин также можно загрузить вручную здесь . После установки мы можем запустить проверку PMD непосредственно из самой IDE:

Стоит отметить, что мы можем запускать PMD на уровне проекта или на уровне отдельного класса.

Результаты показаны ниже — с разными цветами для разных уровней обнаружения, которые варьируются от «предупреждения» до «блокировки» в порядке возрастания серьезности:

Мы можем углубиться в детали каждой записи, щелкнув ее правой кнопкой мыши и выбрав «показать подробности» в контекстном меню. Eclipse отобразит краткое описание проблемы и возможные способы ее решения:

Также возможно изменить конфигурацию сканирования PMD — мы можем сделать это в меню, в разделе «Окно» — > «Настройки» — > «PMD», чтобы открыть страницу конфигурации. Здесь мы можем настроить параметры сканирования, набор правил, настройки отображения результатов и т. д.

Если нам нужно деактивировать какие-то конкретные правила для проекта — мы можем просто убрать их из проверки:

2.2. Интеграция с IntelliJ​

Конечно, у IntelliJ есть похожий плагин PMD — его можно скачать и установить из магазина плагинов JetBrains .

Точно так же мы можем запустить плагин прямо в IDE — щелкнув правой кнопкой мыши источник, который нам нужно просканировать, и выбрав сканирование PMD из контекстного меню:

Результаты отображаются немедленно, но, в отличие от Eclipse, если мы попытаемся открыть описание, откроется браузер с общедоступной веб-страницей для поиска информации:

Мы можем настроить поведение плагина PMD на странице настроек, выбрав «Файл» — > «Настройки» — > «Другие настройки» — > «PMD», чтобы просмотреть страницу конфигурации. На странице настроек мы можем настроить набор правил, загрузив собственный набор правил с нашими собственными правилами тестирования.

3. ДжаКоКо​

Двигаемся дальше: JaCoCo — это инструмент покрытия тестами, используемый для отслеживания покрытия модульными тестами в кодовой базе. Проще говоря, инструмент рассчитывает покрытие, используя ряд стратегий, например: линии, класс, методы и т. д.

3.1. Интеграция с Eclipse​

JaCoCo можно установить прямо из магазина . Ссылка для установки также размещена на официальном сайте, доступном здесь .

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

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

В нашем тестовом примере мы тестируем только сценарий, в котором второй параметр равен нулю:

В этом случае мы видим, что строка 6 окрашена в желтый цвет. В нашем простом тесте проверяется и выполняется только одна ветвь условия «если». Поэтому он не полностью протестирован и отмечен желтым цветом.

Кроме того, строка 7 имеет зеленый цвет — это означает, что она полностью протестирована. Наконец, строка 9 выделена красным цветом, что означает, что эта строка вообще не тестируется нашими модульными тестами.

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

3.2. Интеграция с IntelliJ IDEA​

JaCoCo по умолчанию входит в последний дистрибутив IntelliJ IDEA, поэтому нет необходимости устанавливать плагин отдельно.

При выполнении модульных тестов мы можем выбрать, какой бегун покрытия нам нужно использовать. Мы можем запускать тестовые примеры либо на уровне проекта, либо на уровне класса:

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

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

4. Кобертура​

Наконец, стоит упомянуть Cobertura — он также используется для отслеживания покрытия модульными тестами в кодовой базе.

Последняя версия Eclipse на момент написания статьи не поддерживает подключаемый модуль Cobertura; плагин работает с более ранними версиями Eclipse.

Точно так же IntelliJ IDEA не имеет официального плагина, который может выполнять покрытие Cobertura.

5. Вывод​

Мы рассмотрели интеграцию с Eclipse и IntelliJ IDEA для трех широко используемых инструментов статического анализа. FindBug был рассмотрен в предыдущем введении к FindBugs .

Исходный код этого руководства можно найти в проекте GitHub — это проект на основе Maven, поэтому его легко импортировать и запускать как есть.

Старое ПППП / Лабораторная работа №6 / Лабораторная работа №6. Статический анализатор кода FindBugs

Цель работы: ​ ознакомиться со статическим анализатором кода FindBugs, научиться его использовать для нахождения потенциальных ошибок.

Необходимое ПО для практической части: ​ JDK 8; IntelliJ IDEA 14 Community Edition; Gradle.

Стати́ческий ана́лиз ко́да (англ. static code analysis) — анализ программного обеспечения, производимый (в отличие от динамического анализа) без реального выполнения исследуемых программ. В большинстве случаев анализ производится над какой­либо версией исходного кода, хотя иногда анализу подвергается какой­нибудь вид объектного кода. Термин обычно применяют к анализу, производимому специальным программным обеспечением (ПО), тогда как ручной анализ называют «program understanding», «program comprehension» (пониманием или постижением программы).

В зависимости от используемого инструмента глубина анализа может варьироваться от определения поведения отдельных операторов до анализа, включающего весь имеющийся исходный код. Способы использования полученной в ходе анализа информации также различны — от выявления мест, возможно содержащих ошибки (утилиты типа Lint), до формальных методов, позволяющих математически доказать какие­либо свойства программы (например, соответствие поведения спецификации).

В последнее время статический анализ всё больше используется в верификации свойств ПО, используемого в компьютерных системах высокой надёжности, особенно критичных для жизни (safety­critical). Также применяется для поиска кода, потенциально содержащего уязвимости (иногда это применение называется Static Application Security Testing, SAST).

Большинство компиляторов (например, GNU C Compiler) выводят на экран «предупреждения» (англ. warnings) — сообщения о том, что код, будучи синтаксически правильным, скорее всего, содержит ошибку. Например:

int y = x+2; // Переменная x не инициализирована!

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

FindBugs — статический анализатор кода, который известен тем, что обнаружил ошибку в модели памяти Java. Программа использует статический анализ, чтобы найти потенциальные ошибки сотни различных типов в Java коде. Приложение распространяется и как отдельное десктопное приложение и как плагин к Eclipse, Netbeans, IntelliJ IDEA и Hudson.

FindBugs отлавливает так называемые bug patterns ­ т.e. конструкции в коде, которые, скорее всего, являются ошибкой. Причем, для ее работы не обязательно иметь исходный код приложения ­ на самом деле она выполняет анализ байт­кода, используя для этих целей библиотеку Apache BCEL (ByteCode Engineering Library). Таким образом, можно даже сторонние JARы проанализировать на наличие ошибок ­ FindBugs может обрабатывать JAR­, ZIP­файлы, и, конечно, class­файлы.

С FindBugs можно работать из IntelliJ IDEA, подключив плагин ​ Findbugs­IDEA ​. (Подключение плагинов описано в лабораторной работе №1.) Ниже показана работа плагина версии 0.9.996 c IntelliJ IDEA версии 14.1.2.

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

Практикум по промышленному программированию ­ 2015. Лабораторная работа №6

На скриншоте выделены кнопки “Проанализировать все файлы в проекте” и “Настройки анализа”. Для того, чтобы анализ покрывал все возможные недоработки и ошибки в коде, нужно в настройках анализа задать минимальный показываемый уровень предупреждений как “Низкий”.

После нажатия на кнопку “Проанализировать все файлы в проекте” будет проведен статический анализ всех файлов в проекте, и выведен отчет о найденных ошибках.

У каждой ошибки можно просмотреть её подробное описание, класс ошибки и приоритет (низкий, средний и высокий).

Описания всех ошибок можно посмотреть здесь: ​ http://findbugs.sourceforge.net/bugDescriptions.html ​ .

Отчет по ошибкам в формате XML или HTML можно сформировать с помощью кнопки .

Практикум по промышленному программированию ­ 2015. Лабораторная работа №6

Интеграция FindBugs и Gradle

В Gradle возможно вызывать проверку кода с помощью FindBugs. Подробнее про плагин findbugs в gradle здесь: ​ http://gradle.org/docs/current/userguide/findbugs_plugin.html ​ .

Необходимый сниппет для файла build.gradle: apply plugin: ‘findbugs’

ignoreFailures = true effort = «max» reportLevel = «low»

В этом сниппете также задана генерация отчетов в формате HTML. Они помещаются в директорию \build\reports\findbugs\. Задача, выполняющая все необходимые действия для проверки кода ­ check (она вызывает задачу findbugsMain, но findbugs работает с байт­кодом, поэтому предварительно необходимо скомпилировать код. Поэтому лучше для статической проверки использовать команду check).

Задание для самостоятельной работы

Задание выполняется ​ индивидуально ​.

Необходимо проверить с помощью FindBugs свои выполненные лабораторные работы №3 и 5. Сгенерировать HTML­отчеты об ошибках. Ошибки необходимо исправить. В лабораторной работе №5 статический анализ организовать с помощью Gradle.

Как отключить плагин в intellij idea чтоб тот не участвовал в сборке проекта

В intellij idea используется плагин FindBugs-IDEA v1.0.1. Можно ли как то его отключать на время сборки jar ( но не удаляя его, тк он нужен в проекте ), иначе он сильно грузит систему и компьютером невозможно пользоваться в это время.

Отслеживать
задан 28 фев 2020 в 12:15
289 1 1 золотой знак 5 5 серебряных знаков 19 19 бронзовых знаков

3 ответа 3

Сортировка: Сброс на вариант по умолчанию

Можно лишь отключить перед сборкой, а после снова включить, но каждый раз будет рестарт идеи. Необходимо нажать File->Settings, выбрать вкладку Plugins и отключай нужный тебе плагин.

Отслеживать
ответ дан 26 июн 2020 в 20:14
Ivan Shchipalkin Ivan Shchipalkin

в строку комманды maven для сборки jar нужно добавить -Dимяплагина.skip=true ,например для плагина CheckStyle нужно добавить -Dcheckstyle.skip

Отслеживать
ответ дан 1 июл 2020 в 18:47
289 1 1 золотой знак 5 5 серебряных знаков 19 19 бронзовых знаков

В меню File -> Settings, в открывшемся окне, слева нужно выбрать вкладку Plugins, сверху выбрать вкладку Installed. Далее снимите флаг с плагина, который хотите отключить и нажмите кнопку Apply.

Отслеживать
ответ дан 18 мар 2023 в 0:54
46 2 2 бронзовых знака

• intellij-idea
• плагин

Важное на Мете

Похожие

Подписаться на ленту

Лента вопроса

Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.

Дизайн сайта / логотип © 2024 Stack Exchange Inc; пользовательские материалы лицензированы в соответствии с CC BY-SA . rev 2024.1.3.2953

Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.

SonarQube и IntelliJ IDEA: правильная интеграция

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

На данный момент этот инструмент плотно вошёл в нашу жизнь, следя за единым стилем кода и уберегая от самых разных видов ошибок. Поиск ошибок происходит при сборке на CI или перед принятием pull request в версионное хранилище. Все найденные ошибки отображаются в Web-интерфейсе, где можно изучать их и управлять ими.

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

Для того, чтобы облегчить жизнь разработчикам нашей компании, использующим IntelliJ IDEA, я составил инструкцию. А в дальнейшем понял, что она может быть полезной более широкому кругу специалистов, и решил выложить её в публичный доступ.

Пара слов о моей компании

Так как моя статья — первая в корпоративном блоге НПО «Криста», напишу несколько слов о своей компании.

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

История компании началась в Рыбинске. Туристы иногда посещают наш город, путешествуя на теплоходах по Волге. Ищите его на карте рядом с Рыбинским водохранилищем. Современная география наших производственных центров, филиалов и представительств значительно шире, но главный центр НПО «Криста» по-прежнему находится в Рыбинске.

Для начала посмотрим, какие инспекции вообще поддерживает SonarQube. Прежде всего, это собственные инспекции, идущие в поставке по умолчанию. Но, помимо этого, есть ещё и плагины для интеграции нескольких сторонних анализаторов:

• CheckStyle
• Spotbugs (ранее назывался FindBugs, но переименовался вместе с переименованием самого анализатора)
• PMD

Каждую отдельную инспекцию можно настраивать индивидуально, а также объединять их в профили, позволяя иметь единый набор инспекций для всего предприятия. Так, у нас в основном профиле активировано более 1200 разных инспекций. Понятно, что ни один человек не в состоянии удержать столько правил в голове, а значит, после каждого этапа написания кода следует этап правки замечаний от SonarQube. И чем короче этот этап, тем он менее болезненный для разработчика. Так как же его можно упростить?

Для решения этой проблемы различные IDE имеют плагины, позволяющие вынимать информацию с сервера SonarQube и отображать её прямо в редакторе кода. В случае с IntelliJ IDEA это, прежде всего, SonarLint — официальный плагин от разработчиков самого SonarQube. Он берёт с сервера только профиль с настройками активных инспекций, а сам анализ делает налету прямо в IDE. Это значительно повышает качество разработки, позволяя сразу видеть все новые замечания и оперативно их исправлять. Но тут есть ложка дёгтя. SonarLint работает исключительно с собственными инспекциями SonarQube, полностью игнорируя все остальные инспекции. Замечаний ни от FindBugs, ни от CheckStyle или PMD вы не увидите. А ведь там может содержаться весьма много ценной информации.

Но не стоит отчаиваться: сервер SonarQube умеет экспортировать настройки для всех анализаторов, а значит, имеется возможность настроить штатные плагины IDEA так, чтобы они выдавали результат, эквивалентный серверному.

Давайте разберёмся с этими настройками по порядку.

Настройка SonarLint

Тут нет никаких хитростей. Идём в настройки IDEA и в разделе Plugins находим плагин SonarLint и устанавливаем его.

Изначально плагин использует настройки инспекций по умолчанию. Теперь можно перейти в окно плагина и сконфигурировать подключение к серверу SonarQube. Так как лучше один раз увидеть, чем сто раз прочитать, то просто приведу серию скриншотов последовательности настройки. Здесь и далее красным будут обведены места, требующие к себе внимания. Это или поля для заполнения, или кнопки, которые требуется нажать, или флаги, которые требуется привести к указанному виду:

Главное — не забыть нажать Update binding после добавления нового сервера, чтобы плагин загрузил профиль с настройками. Эту кнопку придётся нажимать всякий раз, когда профиль изменится на сервере (добавили/удалили инспекции, изменили их настройки).

Если у вас подключено несколько модулей в один проект IDEA, то в настройках придётся переключаться на конкретный модуль всякий раз, когда вам его надо будет проанализировать на предмет замечаний. Это не очень удобно, но так есть.

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

Пример того, как выглядит работа с SonarLint можно увидеть ниже (картинка кликабельна):

Если что-то пошло не так

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

Например, после последнего релиза IntelliJ IDEA (2019.2) у меня перестало работать вот с такой ошибкой:

Очень информативно… И самостоятельно догадаться, как получить больше информации, не получилось.

Ситуацию спас F.A.Q. на сайте SonarQube. Оказывается, в окне SonarLint в IDEA можно изменять уровень логирования ошибок:

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

Ага! Теперь ошибка появилась, и стало понятно, что происходит.

По сути, случился неприятный конфликт версий. Наши приложения до сих пор используют Java 8 и проверяются на SonarQube 7.1. При этом весь производственный процесс завязан на возможности SonarQube анализировать разницу в ошибках между основной веткой разработки и Pull Request’ом.

Но самое неприятное, что с версии SonarQube 7.2 эта функция стала платной, из-за чего мы до сих пор не обновились до последней версии. А поддержка Java 11 была реализована только в SonarQube 7.3.

Ещё одним важным моментом является то, что плагин SonarLint при анализе кода в обязательном порядке компилирует исходники с помощью той JRE, на которой запущена IntelliJ IDEA. Пока IDEA работала на Java 8, у нас было всё хорошо. Но вот когда она в версии 2019.2 перешла на использование Java 11, то всё посыпалось, т. к. по факту происходит компиляция в байткод от Java 11 (class file major version 55), а анализируется той версией анализатора, которая установлена на сервере, т. е. не поддерживающей этот формат байткода. И это известная проблема.

Видимо, придётся срочно искать пути обновления SonarQube до последней версии. Возможно, с использованием стороннего плагина sonarqube-community-branch-plugin, предлагающего необходимые нам функции.

Выгрузка настроек анализаторов из SonarQube

Для каждого из плагинов, кроме SonarLint, необходимы свои файлы настроек, каждый — в собственном формате. К счастью, SonarQube умеет выгружать эти файлы. Они находятся в окне настройки профиля анализа.

Для того, чтобы туда попасть, необходимо в Web-интерфейсе сервера SonarQube перейти в раздел Quality Profile и выбрать тот профиль, который используется для анализа проекта:

На открывшейся странице появится раздел, предоставляющий ссылки для экспорта настроек под каждый из анализаторов:

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

Настройка CheckStyle

В IDEA плагин называется CheckStyle-IDEA. Это, пожалуй, самый беспроблемный с точки зрения использования плагин, т. к. позволяет загрузить настройки прямо по URL и не требует переключения между модулями, как SonarLint.

Для подключения конфигурации необходимо перейти в настройки IDEA и выбрать раздел CheckStyle . Далее необходимо добавить новый пункт в таблицу Configuration File :

И указать источник конфигурации:

Также не забываем отметить вновь добавленную конфигурацию как активную в таблице окна настроек.

Всё, теперь можно переходить в окно CheckStyle и запускать анализ (верхняя отмеченная кнопка):

В случае, если профиль на сервере SonarQube поменялся, необходимо обновить настройки путём нажатия соответствующей кнопки в том же окне (нижняя отмеченная кнопка).

Если что-то пошло не так

В случае ошибки «The Checkstyle rules file could not be parsed», а именно «SuppressionCommentFilter is not allowed as a child in Checker», нужно понизить версию Checkstyle в настройках плагина, которая используется на сервере SonarQube. Соответствие версий можно посмотреть в таблице в описании плагина Checkstyle для SonarQube.

Настройка FindBugs

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

Для подключения конфигурации необходимо перейти в настройки IDEA и выбрать раздел FindBugs-IDEA . Далее на вкладке Filter добавить новый пункт в таблицу Include filter files :

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

Важное замечание 1: в настройках плагина имеется вкладка Share , в которой предлагается подключить файл настроек SonarQube. Пользоваться этой настройкой не рекомендую, т. к. корректно не заработало, а вот последствия лечатся нетривиально. Дело в том, что просто удаление этой настройки ничего не дало. Плагин не начал работать нормально. Для восстановления работы пришлось удалить файл .idea/findbugs-idea.xml в каталоге проекта и перенастроить всё заново.

Важное замечание 2: если настройки на сервере SonarQube изменились, то необходимо выгрузить заново на диск.

Важное замечание 3: к огромному сожалению, развитие данного плагина застопорилось после того, как разработка самого FindBugs была переведена в его форк SpotBugs. В багтреккере JetBrains есть тикет на эту тему. Так что если вы наравне с нами захотите полноценную поддержку всех замечаний SonarQube прямо у себя, в любимой IDE, то можно проголосовать за этот тикет. Может, телега-таки сдвинется с места.

Настройка PMD

В IDEA плагин называется PMDPlugin. Аналогично с FindBugs, этот плагин требует наличия файла настроек на диске. Для конфигурирования идём в настройки IDEA и добавляем файл, выгруженный из SonarQube:

Имя файла играет важную роль, т. к. в дальнейшем оно будет использовано плагином для формирования соответствующего пункта меню для запуска анализа.

Также в соседней вкладе необходимо указать ту версию Java, которую использует проект (ну, и кодировку заодно):

Теперь можно запустить анализ текущего файла, воспользовавшись контекстным меню:

Run PMD->Custom Rules->

Важное замечание 1: PMD можно также запустить через главное меню, но делать это не рекомендуется, т. к. в этом случае проверке подвергнется не один файл, а весь открытый в IDE проект. Это может занять много времени и значительно перегрузить систему.

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

Заключение

Резюмируя сказанное, отмечу следующее. Несмотря на то, что для отслеживания замечаний приходится управлять настройками целых 4-х плагинов, это всё же лучше, чем каждый раз ждать, пока результаты редактирования появятся на сервере SonarQube, и позволяет сразу коммитить более чистый код.

Надеюсь, что изложенная здесь информация поможет кому-нибудь легче подружиться со статическими анализаторами вообще и с SonarQube в частности.

Так же хочу поблагодарить коллег, помогавших мне с написанием и поддержкой актуальности этой статьи: Дмитрия Зимичева, Юрия Крупина и Артёма Ганева.