OC静态代码检测方案

背景：

这段时间代码规范问题引起了小编的注意，很多代码不规范的情况导致代码开发效率低，BUG数量多等，于是，为了保证团队开发中代码的规范以及尽量避免低级bug，我们往往需要一些工具来进行严格的检查。小编找到了一套OC的静态代码检测工具。

方案：

本次采用的是Xcode自带命令行xcodebuild的analyze功能，结合oclint工具对项目进行代码检测并生成html文件报告。这里将步骤简单的介绍给大家，希望可以有所帮助。

步骤：

xcodebuild指令

xcode工具其实本身就包含了静态代码分析功能，打开项目后，可通过菜单Product->Analyze来对代码进行扫描。

这种检查方式好处是方便，直接在xcode中运行，并且可以按不同的方式查看静态代码的错误，点击左侧的代码可以直接跳转至有问题的代码。但是不足之处也是显而易见的。对于我们测试同学来说，我们需要的是一个分类统计的结果，逐条列出虽然便于开发直接跳转的结果进行自查修改，但是不方便进行统计。不过xcodebuild指令中也包含analyze可以方便我们调用。

xcodebuild功能非常强大，具体的用法可以通过man xcodebuild来查看。本文中主要使用analyze功能，xcodebuild指令用法的基本介绍如下，需要进入到项目所在目录（projectName.xcproj或workspaceName.xcworkspace文件所在目录）执行。

而在我们普通的项目中只需要workspace和scheme就可以了，具体命令如下：

xcodebuild -workspace workspaceName.xcworkspace-scheme schemeName analyze

OCLint工具

OCLint在本文中的作用是对xcodebuild产生的log进行分析，获取相关数据以后生成html文件或pmd文件。

OCLint是一个开源的项目，你可以通过源码安装，需要设置对应的环境变量，也可以使用作者发布的release进行安装，不过我更习惯使用Homebrew安装。

首先需要设置brew的第三方仓库oclint/formulae。

brewtap oclint/formulae
brewinstall oclint

xcodebuild 与 oclint结合

根据oclint官网的教程，执行如下：

xcodebuildanalyze | tee xcodebuild.log

将xcodebuild analyze的输出信息记录在xcodebuild.log中。

oclint-xcodebuildxcodebuild.log

对log进行解析，生成compile_command.json。但我们可以发现进行到这一步后命令行提示:

This binary isno longer under maintenance by OCLint team.
Pleaseconsider using xcpretty (https://github.com/supermarin/xcpretty) instead!

原因可见，oclint-xcodebuild不在使用了，需要安装xcpretty,使用xcpretty命令分析日志信息。因此转而采用xcpretty。

xcpretty可以用

geminstall xcpretty

下载安装。根据教程,xcpretty可以通过--reportjson-compilation-database来生成oclint所需的json文件。因此合并前两步：

xcodebuildanalyze | tee xcodebuild.log | xcpretty --report json-compilation-database

需要注意的是，这一步生成的json文件在build/reports下，并且名字为compilation_db.json，和oclint默认生成的文件命名和路径均不同，因此需要移动至根目录并重命名为compile_command.json。

最后一步生成html或pmd文件

oclint-json-compilation-database-e Pods -- -report-type html -rc=LONG_LINE=200 -rc=NCSS_METHOD=100-o=report.html

OCLint的分析结果：

优先级的级别是从Priority1, Priority 2, Priority 3 依次降低的 TotalFiles 总文件数 Fileswith Violations 违规文件数 CompilerWarnings 表示项目中的警告⚠ CompilerErrors 表示编译错误 Location表示警告的位置 RuleName 规则名称 Localtion 问题所在位置

通过上述步骤，我们就可以得到相关代码的静态检测结果了，拿到这些结果就可以告诉我们的开发同学需要修改哪些地方。而我们接下来需要做的就是将这套检测工具与持续集成的代码结合在一起并持续去检测代码质量，希望大家都可以在自己的项目中进行使用。