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 -> Preferences -> Checkstyle. В разделе Global Check Configurations нажмите New.
Это откроет диалоговое окно, которое предоставит нам возможность указать наш пользовательский файл конфигурации.
3.2. Просмотр отчетов
Теперь, когда наш плагин настроен, мы можем использовать его для анализа нашего кода.
Чтобы проверить стиль кодирования для проекта, щелкните проект правой кнопкой мыши в проводнике проектов Eclipse и выберите CheckStyle -> Check Code with Checkstyle.
Плагин будет давать нам отзывы о нашем Java-коде в текстовом редакторе Eclipse. Он также создаст отчет о нарушениях для проекта, который доступен в виде представления в Eclipse.
Чтобы просмотреть отчет о нарушении, перейдите в « Окно» -> «Показать вид» -> «Другое » и выполните поиск Checkstyle. Должны отображаться параметры для нарушений и диаграммы нарушений .
Выбор любого из вариантов даст нам представление о нарушениях, сгруппированных по типу. Вот круговая диаграмма нарушений для примера проекта:
Щелчок по разделу круговой диаграммы приведет нас к списку фактических нарушений в коде.
В качестве альтернативы мы можем открыть представление « Проблемы » Eclipse IDE и проверить проблемы, о которых сообщает плагин.
Вот пример просмотра проблем Eclipse IDE:
Нажав на любое из предупреждений, мы перейдем к коду, где произошло нарушение.
4. Плагин IntelliJ IDEA
4.1. Конфигурация
Как и Eclipse, IntelliJ IDEA также позволяет нам использовать в проекте собственные настраиваемые конфигурации.
В IDE откройте «Настройки» и найдите «Checkstyle». Появится окно, в котором есть возможность выбрать наши чеки. Нажмите кнопку + , и откроется окно, в котором мы можем указать местоположение используемого файла.
Теперь мы выбираем XML-файл конфигурации и нажимаем «Далее». Это откроет предыдущее окно и покажет наш недавно добавленный параметр пользовательской конфигурации. Мы выбираем новую конфигурацию и нажимаем OK, чтобы начать использовать ее в нашем проекте.
4.2. Просмотр отчетов
Теперь, когда наш плагин настроен, давайте используем его для проверки нарушений. Чтобы проверить наличие нарушений конкретного проекта, перейдите в Analyze -> 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, является важной частью файла и указывает, откуда следует загрузить 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 .