Android静态代码检查-使用Detekt保持代码库整洁


At Livefront, we’ve taken an initiative in the last year to reduce cognition spent on tasks that can be automated to save our brainwaves for the difficult tasks that count. By automating weekly releases, implementing coverage reporting on our core application logic, and bolstering our usage of static code checks, we’ve made our engineers happier and our codebases cleaner!

在Livefront ，我们在去年采取了一项主动行动，以减少人们对可自动执行的任务的认知，从而节省了脑力，以应对难以计数的困难任务。 通过使每周的发布自动化，在我们的核心应用程序逻辑上实现覆盖率报告以及增强对静态代码检查的使用，我们使工程师更快乐，代码库更清洁！

In this article we’ll focus on setting up detekt, a Kotlin specific linting tool that can enforce codebase documentation, give hints about code blocks that are getting a bit complicated, enforce formatting standards, and sniff out potential bugs before they hatch! Here’s how to get up and running:

在本文中，我们将集中于设置detekt ，这是Kotlin特定的linting工具，可以执行代码库文档，提供有关变得复杂的代码块的提示，强制执行格式标准，并在可能的bug出现之前就对其进行嗅探！ 这是启动和运行的方法：

1)添加detekt gradle插件以构建/渐变1： (1) Add the detekt gradle plugin to build/gradle1:)

1
2
3
4
5
6
7
8
9
10
11
buildscript {
    // ...
    repositories {
        // ...
        maven { url "https://plugins.gradle.org/m2/" }
    }
    dependencies {
        // ...
        classpath "io.gitlab.arturbosch.detekt:detekt-gradle-plugin:1.1.1"
    }
]

2)在应用程序级别build.gradle中引用该插件： (2) Reference that plugin in app level build.gradle:)

1
apply <strong>plugin</strong>: <strong>'io.gitlab.arturbosch.detekt'</strong>

With just those two steps, the detekt gradle plugin automatically defines a handful of new gradle tasks that we can call using the gradle wrapper (??). You can confirm by running the following command from the project root:

仅需执行这两个步骤，detekt gradle插件即可自动定义一些新的gradle任务，我们可以使用gradle包装器(??)调用这些任务。 您可以通过从项目根目录运行以下命令来确认：

1
$ ./gradlew task

You should see a list of gradle tasks, including the brand new detekt ones:

您应该看到gradle任务列表，包括全新的detekt任务：

Image for post

Now that we’re setup, the real fun begins ??! Run the following command to see an initial report on your codebase:

现在我们已经设置好了，真正的乐趣开始了！ 运行以下命令以查看代码库的初始报告：

1
$ ./gradlew detekt

Image for post

Detekt results on a blank codebase
Detekt在空白代码库上的结果

设置配置 (Setting Up A Config)

Detekt is highly configurable to meet your team’s requirements. To start tinkering with configuration, generate a config file by running:

Detekt具有高度可配置性，可以满足您团队的要求。 要开始修改配置，请运行以下命令来生成配置文件：

1
 $ ./gradlew detektGenerateConfig

Open the newly generated file in /config/detekt/detekt.yml to start playing with various configuration options. Here are a few our team has taken advantage of:

在/config/detekt/detekt.yml打开新生成的文件 开始使用各种配置选项。 以下是我们团队利用的一些优势：

  • Setting maxIssues to 0, because why tolerate a codebase that isn’t squeaky clean?

    将maxIssues设置为0 ，因为为什么要容忍不干净的代码库？

  • Enabling UndocumentedPublicClass and UndocumentedPublicFunction to enforce codebase documentation.

    启用UndocumentedPublicClass和UndocumentedPublicFunction强制执行代码库文档。

  • Enabling MissingWhenCase to ensure our when statements are exhaustive.

    启用MissingWhenCase以确保我们的when语句详尽无遗。

  • Enabling ignoreOverridden on the TooManyFunctions check, so that we don’t have to suppress on Activity and Fragment classes that often require many overrides.

    在TooManyFunctions检查中启用ignoreOverridden ，这样我们就不必抑制经常需要多次重写的Activity和Fragment类。

设置格式检查 (Setting Up Formatting Checks)

Out of the box, the detekt gradle plugin will check for Kotlin code smells but does not do any checks on formatting. There is a formatting module that wraps ktlint that can be added by adding the following to your app/build.gradle:

开箱即用的detekt gradle插件将检查Kotlin代码的气味，但不对格式进行任何检查。 有一个包装ktlint的格式化模块，可以通过将以下内容添加到您的app / build.gradle中来添加它 ：

1
2
3
4
5
6
7
8
// ...


dependencies {
    // ...
    detekt("io.gitlab.arturbosch.detekt:detekt-formatting:$detekt_version")
    detekt("io.gitlab.arturbosch.detekt:detekt-cli:$detekt_version")
}

After adding the formatting module, the formatting ruleset in detekt.yml becomes active. Out of the box, it uses the exact same rules as ktlint.

添加格式化模块后， detekt.yml的formatting规则集detekt.yml变为活动状态。 开箱即用，它使用与ktlint完全相同的规则。

如果要添加到现有项目中 (If You’re Adding To An Existing Project)

The correct time to setup static code checks is always “now”, but what if your project is already in production and you have a couple hundred pre existing detekt warnings? Detekt allows you to specify a baseline file of warnings that will be ignored, so only new warnings cause failures. Here’s how to set it up:

设置静态代码检查的正确时间总是“现在”，但是如果您的项目已经投入生产并且您有数百个预先存在的detekt警告，该怎么办？ Detekt允许您指定将被忽略的警告基线文件，因此只有新警告会导致失败。 设置方法如下：

First, run the following command to generate a baseline file:

首先，运行以下命令以生成基准文件：

1
$

Then, add the following detekt config in app/build.gradle:

然后，在app/build.gradle添加以下detekt配置：

1
detekt {<!-- --><br>    // other detekt configuration goes here<br>    baseline = file(“$rootDir/detekt-baseline.xml”)<br>}

Now, when running ./gradlew detekt, warnings listed in the baseline file will be ignored! You can update the baseline file at any time by re-running ./gradlew detektBaseline.

现在，当运行./gradlew detekt ，基线文件中列出的警告将被忽略！ 您可以随时通过重新运行./gradlew detektBaseline来更新基准文件。

All of these static checks are great, but we can get even more value if we run these static checks locally before the CI and code review process. Stay tuned for part II where I’ll show how we use git pre-push hooks to catch lint and formatting errors before code review.

所有这些静态检查都很棒，但是如果在配置项和代码审查过程之前在本地运行这些静态检查，我们可以获得更大的价值。 请继续关注第二部分，在该部分中，我将展示在代码检查之前我们如何使用git pre-push钩子捕获lint和格式错误。

Andrew is an Android engineer at Livefront. He loves making apps so much, some of his friends even call him Android!

Andrew是Livefront的一名Android工程师。 他非常喜欢制作应用，他的一些朋友甚至称他为Android！

脚注： (Footnotes:)

  1. You can always find the latest version here: https://plugins.gradle.org/plugin/io.gitlab.arturbosch.detekt 您总是可以在这里找到最新版本：https://plugins.gradle.org/plugin/io.gitlab.arturbosch.detekt