CheckStyle 简介

codingman included in DevOps Java

2018-08-26 2573 words 6 minutes

Contents

1. 概述

Checkstyle 是一个开源工具，可以根据一组可配置的规则检查代码。

在本教程中，我们将了解如何通过 Maven 和使用 IDE 插件将Checkstyle 集成到 Java 项目中。

以下部分中提到的插件不相互依赖，可以单独集成到我们的构建或 IDE 中。例如，我们的pom.xml中不需要 Maven 插件来在我们的 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命令为我们的代码生成报告。构建完成后，该报告在名为checkstyle.html的target/site文件夹中可用。

Checkstyle 报告包含三个主要部分：

Files：报告的这一部分为我们提供了发生违规行为的文件列表。它还向我们展示了违反严重程度的计数。报告的文件部分如下所示：

Rules：报告的这一部分概述了用于检查违规行为的规则。它显示了规则的类别、违规的数量以及这些违规的严重性。以下是显示规则部分的报告示例：

Details：最后，报告的详细信息部分向我们提供了已发生违规行为的详细信息。提供的详细信息是行号级别的。以下是报告的示例详细信息部分：

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 只运行插件的check目标，而无需配置执行目标。如果存在任何验证错误，运行此步骤也会导致构建失败。

3. Eclipse 插件

3.1. 配置

就像 Maven 集成一样，Eclipse 使我们能够使用我们的自定义配置。

要导入我们的配置，请转到Window -> Preferences -> Checkstyle。在Global Check Configurations部分，单击New。

这将打开一个对话框，为我们提供指定自定义配置文件的选项。

3.2. 报告浏览

现在我们的插件已经配置好了，我们可以使用它来分析我们的代码。

要检查项目的编码风格，请在Eclipse Project Explorer中右键单击项目并选择CheckStyle -> Check Code with Checkstyle。

**该插件将在 Eclipse 文本编辑器中为我们提供有关 Java 代码的反馈。**它还将为项目生成违规报告，该报告可作为 Eclipse 中的视图使用。

要查看违规报告，请转到Window -> Show View -> Other，然后搜索 Checkstyle。应显示违规选项和违规图表。

选择任一选项将为我们提供按类型分组的违规表示。以下是示例项目的违规饼图：

单击饼图的一部分将带我们进入代码中实际违规的列表。

或者，我们可以打开 Eclipse IDE 的问题视图并检查插件报告的问题。

这是 Eclipse IDE 的示例问题视图：

单击任何警告都会将我们带到发生违规的代码。

4. IntelliJ IDEA 插件

4.1. 配置

与 Eclipse 一样，IntelliJ IDEA 也使我们能够在项目中使用我们自己的自定义配置。

在 IDE 中打开设置并搜索 Checkstyle。将显示一个窗口，可以选择我们的支票。单击**+**按钮，将打开一个窗口，让我们指定要使用的文件的位置。

现在，我们选择一个配置 XML 文件并单击 Next。这将打开上一个窗口并显示我们新添加的自定义配置选项。我们选择新配置并单击 OK 开始在我们的项目中使用它。

4.2. 报告浏览

现在我们的插件已经配置好了，让我们用它来检查违规行为。要检查特定项目的违规行为，请转到Analyze -> Inspect Code。

**检查结果将让我们查看 Checkstyle 部分下的违规情况。**这是一个示例报告：

单击违规将带我们到文件中发生违规的确切行。

5. 自定义 Checkstyle 配置

在 Maven 报告生成部分（第 2.2 节）中，我们使用自定义配置文件来执行我们自己的编码标准检查。

如果我们不想使用打包的 Google 或 Sun 检查，我们可以创建自己的自定义配置 XML 文件。

这是用于上述检查的自定义配置文件：

<!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，它代表模块的作用。**name属性的值对应于插件代码中的一个类，该类在插件运行时执行。

让我们了解上面配置中存在的不同模块。

5.3. 模块详情

**Checker：**模块在以 Checker 模块为根的树中结构化。该模块定义了配置的所有其他模块继承的属性。
**TreeWalker：**此模块检查各个 Java 源文件并定义适用于检查此类文件的属性。
**AvoidStarImport：**该模块为在我们的 Java 代码中不使用 Star 导入设置了一个标准。它还有一个属性，要求插件将此类问题的严重性报告为警告。因此，只要在代码中发现此类违规行为，就会针对它们标记警告。

要阅读有关自定义配置的更多信息，请点击此链接。

6. Spring-Rest 项目的报表分析

6.1. 生成违规报告

我们已将配置导入 Eclipse IDE，这是为项目生成的违规报告：

此处报告的警告表示应在代码中避免通配符导入。我们有两个文件不符合这个标准。当我们单击警告时，它会将我们带到存在违规的 Java 文件。

以下是HeavyResourceController.java文件如何显示报告的警告：

6.2. 问题解决

使用 Star 导入通常不是一个好习惯，因为当两个或多个包包含相同的类时，它会产生冲突。

例如，考虑类List，它在包java.util和java.awt中都可用。如果我们同时使用 java.util.* 和 java.awt.* 的导入，我们的编译器将无法编译代码，因为List在两个包中都可用。

**为了解决上述问题，我们在两个文件中组织导入并保存它们。**现在，当我们再次运行插件时，我们看不到违规行为，并且我们的代码现在遵循自定义配置中设置的标准。