«Введение в CheckStyle» - Spring на русском

«1. Обзор

Checkstyle — это инструмент с открытым исходным кодом, который проверяет код на соответствие настраиваемым наборам правил.

В этом уроке мы рассмотрим, как интегрировать Checkstyle в проект Java через Maven и с помощью плагинов IDE.

Плагины, упомянутые в следующих разделах, не зависят друг от друга и могут быть интегрированы по отдельности в нашу сборку или IDE. Например, подключаемый модуль Maven не нужен в нашем pom.xml для запуска проверок в нашей Eclipse IDE.

2. Плагин Checkstyle Maven

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

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

<reporting>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-checkstyle-plugin</artifactId>
            <version>3.0.0</version>
            <configuration>
                <configLocation>checkstyle.xml</configLocation>
            </configuration>
        </plugin>
    </plugins>
</reporting>

Этот плагин поставляется с двумя предопределенными проверками, проверкой в стиле Sun и Проверка в стиле Google. Проверка по умолчанию для проекта — sun_checks.xml.

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

Последнюю версию плагина можно найти на Maven Central.

2.2. Создание отчета

Теперь, когда наш подключаемый модуль Maven настроен, мы можем создать отчет для нашего кода, выполнив команду mvn site. После завершения сборки отчет будет доступен в папке target/site под именем checkstyle.html.

Отчет Checkstyle состоит из трех основных частей:

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

Правила: Эта часть отчета дает нам обзор правил, которые использовались для проверки нарушений. Он показывает категорию правил, количество нарушений и серьезность этих нарушений. Вот пример отчета, в котором показан раздел правил:

Подробности: наконец, раздел подробностей отчета предоставляет нам подробности о произошедших нарушениях. Подробная информация представлена на уровне номера строки. Вот примерный раздел отчета:

2.3. Интеграция сборки

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

Мы делаем это, добавляя цель выполнения в определение нашего плагина:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-checkstyle-plugin</artifactId>
    <version>${checkstyle-maven-plugin.version}</version>
    <configuration>
        <configLocation>checkstyle.xml</configLocation>
    </configuration>
    <executions>
        <execution>
            <goals>
                <goal>check</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Атрибут configLocation определяет, к какому файлу конфигурации обращаться для проверки.

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

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

Мы также можем запустить только цель проверки плагина, используя mvn checkstyle:check, без настройки цели выполнения. Выполнение этого шага также приведет к сбою сборки, если есть какие-либо ошибки проверки.

3. Плагин Eclipse

3.1. Конфигурации

Как и в случае с интеграцией Maven, Eclipse позволяет нам использовать нашу пользовательскую конфигурацию.

Чтобы импортировать нашу конфигурацию, перейдите в Window -\u003e Preferences -\u003e Checkstyle. В разделе Global Check Configurations нажмите New.

Это откроет диалоговое окно, которое предоставит нам возможность указать наш пользовательский файл конфигурации.

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

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

Чтобы проверить стиль кодирования для проекта, щелкните проект правой кнопкой мыши в Eclipse Project Explorer и выберите CheckStyle -\u003e Check Code with Checkstyle.

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

«Чтобы просмотреть отчет о нарушении, перейдите в «Окно» -\u003e «Показать представление» -\u003e «Другое» и выполните поиск Checkstyle. Должны отображаться параметры для нарушений и диаграммы нарушений.

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

Нажав на часть круговой диаграммы, мы перейдем к списку фактических нарушений в коде.

В качестве альтернативы мы можем открыть представление «Проблемы» Eclipse IDE и проверить проблемы, о которых сообщает плагин.

Вот пример просмотра проблем Eclipse IDE:

Щелчок по любому из предупреждений приведет нас к коду, где произошло нарушение.

4. Плагин IntelliJ IDEA

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

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

В IDE откройте Настройки и найдите Checkstyle. Появится окно, в котором есть возможность выбрать наши чеки. Нажмите кнопку +, и откроется окно, в котором мы можем указать местоположение используемого файла.

Теперь мы выбираем XML-файл конфигурации и нажимаем «Далее». Это откроет предыдущее окно и покажет наш недавно добавленный параметр пользовательской конфигурации. Мы выбираем новую конфигурацию и нажимаем OK, чтобы начать использовать ее в нашем проекте.

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

Теперь, когда наш плагин настроен, давайте используем его для проверки нарушений. Чтобы проверить наличие нарушений конкретного проекта, перейдите в Analyze -\u003e Inspect Code.

Результаты проверок дадут нам представление о нарушениях в разделе Checkstyle. Вот пример отчета:

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

5. Пользовательская конфигурация Checkstyle

В разделе создания отчета Maven (раздел 2.2) мы использовали пользовательский файл конфигурации для выполнения наших собственных стандартных проверок кодирования.

У нас есть способ создать собственный XML-файл пользовательской конфигурации, если мы не хотим использовать упакованные проверки Google или Sun.

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

<!DOCTYPE module PUBLIC
  "-//Puppy Crawl//DTD Check Configuration 1.3//EN"
  "http://www.puppycrawl.com/dtds/configuration_1_3.dtd">
<module name="Checker">
    <module name="TreeWalker">
        <module name="AvoidStarImport">
            <property name="severity" value="warning" />
        </module>
    </module>
</module>

5.1. Определение DOCTYPE

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

Если мы не включим это определение в наш файл конфигурации, он не будет действительным файлом конфигурации.

5.2. Модули

Файл конфигурации в основном состоит из модулей. У модуля есть имя атрибута, которое представляет, что делает модуль. Значение атрибута name соответствует классу в коде плагина, который выполняется при запуске плагина.

Давайте узнаем о различных модулях, представленных в конфигурации выше.

5.3. Детали модуля

Checker: Модули структурированы в виде дерева, в корне которого находится модуль Checker. Этот модуль определяет свойства, которые наследуются всеми другими модулями конфигурации. TreeWalker: этот модуль проверяет отдельные исходные файлы Java и определяет свойства, применимые для проверки таких файлов. ИзбегайтеStarImport: этот модуль устанавливает стандарт для отказа от использования импорта Star в нашем коде Java. У него также есть свойство, которое просит плагин сообщать о серьезности таких проблем в качестве предупреждения. Таким образом, всякий раз, когда такие нарушения будут обнаружены в коде, против них будет помечено предупреждение.

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

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

В этом разделе мы собираемся пролить свет на анализ, выполненный Checkstyle с использованием пользовательской конфигурации, созданной в разделе 5 выше, для Spring- rest проект доступен на GitHub в качестве примера.

6.1. Генерация отчета о нарушениях

Мы импортировали конфигурацию в Eclipse IDE, и вот отчет о нарушениях, сгенерированный для проекта:

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

Вот как файл HeavyResourceController.java показывает предупреждение:

6.2. Решение проблемы

Использование импорта Star в целом не рекомендуется, так как это может привести к конфликтам, когда два или более пакета содержат один и тот же класс.

В качестве примера рассмотрим класс List, который доступен в пакетах java.util и java.awt. Если мы используем оба импорта java.util .* и java.awt.*, наш компилятор не сможет скомпилировать код, так как List доступен в обоих пакетах.

Чтобы решить проблему, упомянутую выше, мы организуем импорт в обоих файлах и сохраняем их. Теперь, когда мы снова запускаем плагин, мы не видим нарушений, и наш код теперь соответствует стандартам, установленным в нашей пользовательской конфигурации.

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

В этой статье мы рассмотрели основы интеграции Checkstyle в наш проект Java.

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

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

«Введение в CheckStyle»