Введение в FindBugs

1. Обзор

FindBugs — это инструмент с открытым исходным кодом, используемый для статического анализа кода Java.

В этой статье мы рассмотрим настройку FindBugs в проекте Java и ее интеграцию в IDE и сборку Maven.

2. Плагин FindBugs Maven

2.1. Конфигурация Maven

Чтобы начать генерировать отчеты статического анализа, нам сначала нужно добавить плагин FindBugs в наш pom.xml :

<reporting>
    <plugins>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>findbugs-maven-plugin</artifactId>
            <version>3.0.4</version>
        </plugin>
    </plugins>
</reporting>

Вы можете проверить последнюю версию плагина на Maven Central.

2.2. Генерация отчета

Теперь, когда мы правильно настроили подключаемый модуль Maven, давайте сгенерируем проектную документацию с помощью команды mvn site .

Отчет будет создан в папке target/site в каталоге проекта под именем findbugs.html .

Вы также можете запустить команду mvn findbugs:gui , чтобы запустить интерфейс GUI и просмотреть сгенерированные отчеты для текущего проекта.

Плагин FindBugs также можно настроить на сбой при некоторых обстоятельствах, добавив в нашу конфигурацию проверку цели выполнения:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>findbugs-maven-plugin</artifactId>
    <version>3.0.4</version>
    <configuration>
        <effort>Max</effort>
    </configuration>
    <executions>
        <execution>
            <goals>
                <goal>check</goal>
            </goals>
        </execution>
    </executions>
</plugin>

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

Теперь вы можете запустить команду mvn verify , чтобы проверить, будет ли сборка успешной или нет — в зависимости от дефектов, обнаруженных во время анализа.

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

<configuration>
    <onlyAnalyze>org.foreach.web.controller.*</onlyAnalyze>
    <omitVisitors>FindNullDeref</omitVisitors>
    <visitors>FindReturnRef</visitors>
</configuration>

Параметр onlyAnalyze объявляет разделенные запятыми значения классов/пакетов, подходящих для анализа.

Параметры Посетители / omitVisitors также являются значениями, разделенными запятыми, они используются для указания, какие детекторы должны/не должны запускаться во время анализа. Обратите внимание, что посетители и omitVisitors не могут использоваться одновременно .

Детектор определяется именем своего класса без какой-либо квалификации пакета. Подробную информацию обо всех доступных именах классов детекторов можно найти по этой ссылке .

3. Плагин FindBugs Eclipse

3.1. Монтаж

Установка плагина FindBugs в среде IDE довольно проста — вам просто нужно использовать функцию обновления программного обеспечения в Eclipse со следующим сайтом обновлений: http://findbugs.cs.umd.edu/eclipse .

Чтобы убедиться, что FindBugs правильно установлен в вашей среде Eclipse, найдите параметр FindBugs в Windows -> Preferences -> Java.

3.2. Просмотр отчетов

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

После запуска Eclipse показывает результаты в окне Bug Explorer, как показано на снимке экрана ниже:

Начиная со второй версии, FindBugs начал ранжировать ошибки по шкале от 1 до 20 для измерения серьезности дефектов:

• Самый страшный : место между 1 и 4.
• Страшно : место между 5 и 9.
• Тревожный : рейтинг между 10 и 14.
• Вызывает озабоченность : занимает место между 15 и 20.

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

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

3.3. Конфигурация затмения

Плагин FindBugs упрощает настройку стратегии анализа ошибок, предлагая различные способы фильтрации предупреждений и ограничения строгости результатов. Вы можете проверить интерфейс конфигурации, перейдя в Window -> Preferences -> Java -> FindBugs:

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

FindBugs делит дефекты на множество категорий:

• Корректность — собирает общие ошибки, например, бесконечные циклы, неправильное использование equals() и т . д.
• Плохая практика , например обработка исключений, открытые потоки, сравнение строк и т. д.
• Производительность , например, бездействующие объекты
• Многопоточная корректность — собирает несоответствия синхронизации и различные проблемы в многопоточной среде.
• Интернационализация - собирает проблемы, связанные с кодировкой и интернационализацией приложения.
• Уязвимость вредоносного кода — собирает уязвимости в коде, например фрагменты кода, которые могут быть использованы потенциальными злоумышленниками.
• Безопасность — собирает дыры в безопасности, связанные с определенными протоколами или SQL-инъекциями.
• Dodgy — собирает запахи кода , например, бесполезные сравнения, нулевые проверки, неиспользуемые переменные и т. д.

На вкладке « Конфигурация детектора » вы можете проверить правила, которые вы должны соблюдать в своем проекте:

Атрибут скорости показывает, насколько затратным будет анализ . Самый быстрый детектор, самые маленькие ресурсы, потребляемые для его выполнения.

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

На панели « Фильтр файлов » вы можете создавать собственные фильтры файлов, чтобы включать/исключать части базы кода. Эта функция полезна, например, когда вы хотите предотвратить появление «неуправляемого» или «мусорного» кода, появление дефектов в отчетах или, например, исключить все классы из тестового пакета.

4. Плагин IntelliJ IDEA FindBugs

4.1. Монтаж

Если вы являетесь поклонником IntelliJ IDEA и хотите начать проверять код Java с помощью FindBugs, вы можете просто взять установочный пакет плагина с официального сайта JetBrains и извлечь его в папку %INSTALLATION_DIRECTORY%/plugins. Перезапустите IDE, и все готово.

Кроме того, вы можете перейти в «Настройки» -> «Плагины» и выполнить поиск плагина FindBugs во всех репозиториях.

На момент написания этой статьи версия 1.0.1 плагина IntelliJ IDEA только что вышла,

Чтобы убедиться, что подключаемый модуль FindBugs установлен правильно, проверьте параметр «Анализ кода проекта» в разделе «Анализ -> FindBugs».

4.2. Просмотр отчетов

Чтобы запустить статический анализ в IDEA, нажмите «Анализ кода проекта» в разделе «Анализ» -> «Найти ошибки», затем найдите панель «Найти ошибки-IDEA», чтобы проверить результаты:

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

1. Сгруппировать по категории ошибки.
2. Группировка по классу.
3. Сгруппировать по пакету.
4. Сгруппировать по рангу ошибки.

Также можно экспортировать отчеты в формате XML/HTML, нажав кнопку «Экспорт» в четвертом столбце команд.

4.3. Конфигурация

Страницы настроек плагина FindBugs внутри IDEA говорят сами за себя:

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

Доступ к панели настроек можно получить внутри IDEA, щелкнув значок «Настройки плагина» под панелью FindBugs-IDEA.

5. Анализ отчета для проекта Spring-Rest

В этом разделе мы собираемся пролить свет на статический анализ, выполненный в проекте spring-rest, доступном на Github в качестве примера:

Большинство дефектов незначительные — «Вызывает озабоченность», но давайте посмотрим, что мы можем сделать, чтобы исправить некоторые из них.

Метод игнорирует исключительное возвращаемое значение:

File fileServer = new File(fileName);
fileServer.createNewFile();

Как вы, наверное, догадались, FindBugs жалуется на то, что мы отбрасываем возвращаемое значение метода createNewFile() . Возможное исправление состоит в том, чтобы сохранить возвращаемое значение во вновь объявленной переменной, а затем записать что-нибудь значимое, используя уровень журнала DEBUG — например, « Именованный файл не существует и был успешно создан », если возвращаемое значение истинно.

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

try {
    DateFormat dateFormat 
      = new SimpleDateFormat("yyyy_MM_dd_HH.mm.ss");
    String fileName = dateFormat.format(new Date());
    File fileServer = new File(fileName);
    fileServer.createNewFile();
    byte[] bytes = file.getBytes();
    BufferedOutputStream stream 
      = new BufferedOutputStream(new FileOutputStream(fileServer));
    stream.write(bytes);
    stream.close();
    return "You successfully uploaded " + username;
} catch (Exception e) {
    return "You failed to upload " + e.getMessage();
}

Когда перед инструкцией stream.close() генерируется исключение , поток никогда не закрывается, поэтому всегда предпочтительнее использовать блок finally{} для закрытия потоков, открытых во время процедуры try / catch .

Exception перехватывается, когда Exception не сгенерировано : Как вы, возможно, уже знаете, перехват Exception является плохой практикой кодирования, FindBugs считает, что вы должны перехватывать наиболее конкретное исключение, чтобы вы могли правильно с ним справиться. Таким образом, в основном манипулируя потоками в классе Java, перехват IOException был бы более подходящим, чем перехват более общего исключения.

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

6. Заключение

В этой статье мы рассмотрели основные ключевые моменты использования и настройки FindBugs в проекте Java.

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

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

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