本文介绍了kotlin码扫描工具detekt的基本使用方法，并在此基础上总结了kotlin码规范的管理技巧。
引言近期团队对代码规范进行了管理，借此机会调查了Kotlin语言代码扫描工具的使用，探索了针对Kotlin语言的代码规范管理方案。
代码规范检查不仅在团队中推动代码审查，而且经常依赖静态代码分析工具来自动检查和修改代码规范。
与Java语言的checkstyle工具一样，kotlin也有两个类似的静态代码分析工具。
ktlint:kotlin linter工具。 自动格式化代码。 默认规则集扫描代码格式问题。 detekt )同样适用于kotlin语言的静态代码分析工具，不仅可以扫描代码格式问题(集成了Ktlint功能)，还可以扫描代码样式问题和潜在风险。 因为detekt涵盖了Ktlint的功能，所以直接选择detekt作为代码扫描工具。
使用detekt治理kotlin代码配置detekt使用detekt的第一步是在Gradle工程中部署detekt插件。
访问detekt需要三个步骤才能在gradle项目中使用detekt，如官方文档中所述。
Step1:在项目根目录下的build.gralde文件中部署detekt gradle plugin :
//root build.gradlebuildscript { repositories { j center (}//detektgradleplugin插件的部署，以及版本plugins { id (io.) )
//root build.gradledetekt { input=files (' src/main/kot Lin '， ' src/main/java ' )//指定要扫描的源代码文件路径config=files (' config/dete kt.yml ) /要使用的规则集文件reports(//指定输出的报告指定disable html report (default : true ) destination=file (' build/reports/dete kt.html ' )/pathwherehtmlreportwiort
step3:运行./gradlewdetekt命令即可。 扫描结果可以直接在终端上确认，直接移动到问题代码上。
也可以在build/reprots/路径中查看输出的报告文件。
在包含多个将detekt应用于子模块的子模块的项目中，如果要分模块扫描代码，还可以在subprojects闭包中部署detekt插件。 这样，您就可以根据需要扫描不同的模块，而不是每次都扫描所有代码。
Step1:配置时，必须在子模块中部署和配置detekt插件。
//root build.gradlebuildscript (存储库) Google (j center ) }dependencies (从属路径' com.Android.tools )。 AGP版本兼容性class path ' org.jetbrains.kot Lin : kot Lin-grad le-plugin :1.4.10 ' class path ' io.git lab.Artur bob 添加此处为每个模块添加detekt扫描subprojects { apply plugin : ' io.git lab.Artur bosch.dete kt ' tasks.dete kt.JVM target=' ' detekt_config.yml ' ) reports { html.enabled=true } }}请注意这里有一个孔。 最新的detekt 1.16.0-RC1与AGP4.1兼容。 如果使用更旧的版本
步骤2 :执行./gradl
ew detekt会分模块扫描，也可以运行./gradlew app:detekt只扫描app模块这个模块下的代码。结果报告也会在对应模块的build路径下生成。 制定规则集在进行代码规范整改之前，还需要制定规范规则，这样才能有的放矢地进行代码整改。
如果没有在detekt闭包中指定config属性，detekt会使用默认的规则。这些规则采用yaml文件描述，运行./gradlew detektGenerateConfig会生成config/detekt/detekt.yml文件，我们可以在这个文件的基础上制定代码规范准则。
detekt.yml中的每条规则形如：
complexity:# 大类 active: true ComplexCondition:# 规则名 active: true# 是否启用 threshold: 4# 有些规则，可以设定一个阈值# ...更多关于配置文件的修改方式，请参阅官方文档-配置文件。
detekt的规则集划分为9个大类，每个大类下有具体的规则：
规则大类说明comments与注释、文档有关的规范检查complexity检查代码复杂度，复杂度过高的代码不利于维护coroutines与协程有关的规范检查empty-blocks空代码块检查，空代码应该尽量避免exceptions与异常抛出和捕获有关的规范检查formatting格式化问题，detekt直接引用的ktlint的格式化规则集naming类名、变量命名相关的规范检查performance检查潜在的性能问题potentail-bugs检查潜在的BUGstyle统一团队的代码风格，也包括一些由detekt定义的格式化问题更细节的规则说明，请参阅规则集说明 。
代码整改小技巧在代码整改过程中，借助detekt提供的诸多功能，可以极大地提升效率。
自动格式化代码对于formatting类别下的规则，都包含有autoCorrect这个属性选项，这表示是否需要在扫描代码的同时，自动对代码执行格式化。这个功能可以极大地方便大家整改与格式有关的代码问题。
要启用这个功能，还需要引入formatting插件，它是detekt提供的插件，打包了ktlint的功能，使用时配置如下：
detekt { // ... autoCorrect = true // 自动格式化代码的总开关}dependencies { detektPlugins "io.gitlab.arturbosch.detekt:detekt-formatting:[version]"}在实际使用的时候，如果开启自动格式化的功能，运行时可能会报IndexOutOfBoundsException的错误，原因是格式化时会修改原文件，导致执行其它规则的扫描时产生异常，一种解决办法是，另外配置一个专门用于执行格式化的task，它所指定的规则集只开启format类别的规则：
// root build.gradlesubprojects { apply plugin: "io.gitlab.arturbosch.detekt" dependencies { detektPlugins "io.gitlab.arturbosch.detekt:detekt-formatting:$detekt_version" } // 专门用于format的task task detektFormat(type: io.gitlab.arturbosch.detekt.Detekt) { description = "Reformat kotlin code." config.setFrom(files("$rootDir/config/detekt/detekt_${detekt_version}_format.yml")) setSource(files("$projectDir/src/main")) autoCorrect = true include("**/*.kt") }} 对单个文件执行检查detekt除了可以在gradle中配置使用，还可以通过CLI命令行的方式使用。下载detekt-cli-1.15.0-all.jar就可以通过运行java -jar的方式在终端中运行detekt。其它版本可以从此下载。如果还需要扫描格式化相关规则，还需要引入detekt-formatting-1.15.0.jar。
基于这个特性，我们可以在AS中配置External Toos，就可以在对编辑器当前打开的文件执行detekt扫描，这样可以方便我们在整改代码时，实时查看整改进度，而不用每次执行全局扫描，有助于提升整改代码的效率。
Step1：配置（Preferences > Tools > External Toos）
其中的CLI参数配置配置如下
Step2：在已打开的文件空白处，点击右键菜单 > External Tools > detekt_formater即可运行，结果会在控制台中输出。
通过配置文件可以开启或关闭某些规则，但如果仅仅想忽略某些文件中某些问题，而不是直接关闭这类问题的扫描，detekt提供了两种方式来绕过（原文是suppress issue，直译成压制问题，意译的话，可以解释为成绕过检查）。
第一种方式是使用@Suppress注解:
在类名或者方法名前添加诸如@Suppress("LargeClass")这样的注解，可以有针对性地忽略这个文件中的某些告警。
在文件头添加@file:Suppress("TooManyFunctions"),则可以直接告诉detekt不扫描这个文件中的这类问题。
第二种方式是通过基线文件，好处是不会因为添加了@Suppress注解而污染原代码。另一方面，对于臃肿的历史代码，可能没有时间来完全重构，如果直接添加@Suppress绕过整个文件，那么如果下次修改了这个文件，引入的新问题可能也会被绕过。
这种场景，就可以运行./gradew detektBaseline来生成一个baseline.xml基线文件。有了这个基线文件，下次扫描时，就会绕过文件中列出的基线问题，而只提示新增问题。
高亮问题detekt还提供了IntelliJ插件，简单配置后，就可以在编辑器中高亮显示，代码中存在问题。便于我们在代码编写的过程中，留意存在的代码问题。
高亮的效果和IDE自带的inspection的代码提示效果类似，鼠标移动到高亮的地方后会显示问题提示。
可以说，detekt为我们提供了一套完整的kotlin代码规范治理方案。
总结整改老代码是个费时费力的活，本文所讨论的detekt的使用方法，可以一定程度上提升整改的效率。此外，借助detekt这类静态代码扫描工具，也可以在平时开发的过程中，时刻反馈代码质量问题，避免潜在的代码缺陷。
这次也是借这“代码质量治理”这股东风，对项目历史代码进行了整改。但是，整改不仅仅是为了提高质量得分，更重要的是要提高代码规范的意识，在平时的开发过程中就注重写出规范的代码，如此，才能保证软件的质量。