Введение в CheckStyle

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

This plugin comes with two predefined checks, a Sun-style check, and a Google-style check. Проверка по умолчанию для проектаsun_checks.xml.

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

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

Теперь, когда наш плагин Maven настроен, мы можем сгенерировать отчет для нашего кода, выполнив командуmvn site. Once the build finishes, the report is available in the target/site folder under the name checkstyle.html.

В отчете Checkstyle есть три основные части:

Files: В этом разделе отчета содержитсяthe list of files in which the violations have happened. Он также показывает нам количество нарушений по степени их серьезности. Вот как выглядит раздел файлов отчета:

Rules: Эта часть отчета дает намoverview of the rules that were used to check for violations. Он показывает категорию правил, количество нарушений и серьезность этих нарушений. Вот пример отчета, который показывает раздел правил:

Details: Наконец, подробный раздел отчета предоставляет намdetails of the violations that have happened. Предоставленная информация находится на уровне номера строки. Вот типовой раздел отчета:

Если есть необходимость в строгой проверке стиля кодирования,we can configure the plugin in such a way that the build fails when the code doesn’t adhere to the standards.

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

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

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

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

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

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

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

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

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

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

The plugin will give us feedback on our Java code within the Eclipse, text editor. Он также сгенерирует отчет о нарушении для проекта, который доступен в виде представления в Eclipse.

Чтобы просмотреть отчет о нарушении, перейдите кWindow → Show View → Other и найдите Checkstyle. Должны отображаться параметры дляViolations иViolations Chart.

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

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

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

Вот пример проблемы в Eclipse IDE:

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

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

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

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

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

The Inspections Results will give us a view of the violations under the Checkstyle section. Вот пример отчета:

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

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

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

Файл конфигурации в основном состоит из модулей. A module has an attribute name which represents what the module does. Значение атрибутаname соответствует классу в коде плагина, который выполняется при запуске плагина.

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

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

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

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

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

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

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

To resolve the issue mentioned above we organize the imports in both files and save them. Теперь, когда мы снова запускаем плагин, мы не видим нарушений, и теперь наш код соответствует стандартам, установленным в нашей пользовательской конфигурации.