写在前面的话

最近有点发懒筋很长没有计划,没有时间,来更新这里的文章。
这篇文章会简略的写一下SwiftLint的使用流程。

其实是沉迷打CSGO,咳咳。
枪打的不咋地,饰品倒是买了一大堆。

静态分析

之前在学习iOS开发高手课的时候,曾经被又被重新科普了一遍“静态分析”的作用与使用方法。
静态分析,依据我自己的理解,基本是通过全量扫描的形式,来发现一些代码上的错误:

  • 格式是否正确,有没有声明类的时候左右有没有多一个空格,少一个空格;
  • 变量命名是否正确,有没有一会用下划线命名法,一会用驼峰命名法;
  • 是否对显而易见的空类型进行了强制解包操作;
  • ...

一些通过字符串分析能找到的错误,都可以用静态分析来解决。
而其中SwiftLintOCLint是比较常用的工具。

那让我们来实践一下,静态分析,都能找出些什么?

SwiftLint

最近才知道SwiftLint是Realm团队开发的工具,Realm就是那个和对标CoreData的跨平台数据库管理方案。
曾经使用过一次,但是后续的项目中都没有嵌入这么一个编译很慢的庞然大物的必要,所以已经很久没有接触了。

SwiftLint的项目地址在这里
它的安装有好几种方式,我们选择最常用的HomeBrew的方式即可。

常用命令

记住以下几个常用命令就足够了:

 

先用cd定位到工程项目目录,然后使用第一个命令试试。
随后会生成一个HTML格式的结果文件,下面我统一称呼为Report,看看里面的内容是什么。

啊!可以发现SwiftLint把Pod等第三方组件库的内容也扫描进去了,这不是我们写的代码呀。
为了减少结果的条目,需要设置一下配置文件。

配置文件

在刚才的工程项目目录下新建一个名为“.swiftlint.yml”的文件,并填充以下内容。需要注意的是include要写你自己的源代码文件夹,并且记得保存一下:

再试试刚才的命令,结果就会少很多:

但是滑下去一看,很多地方都被提示“Lines should not have trailing whitespace.”:

这个描述对应的规则(Rule)名称叫“trailing_whitespace”,是一个格式化相关的问题。此项其实不是很重要,因为每个人都有自己的空行的习惯。

所以,在设置文件中把“trailing_whitespace”给排除掉:

再次运行下刚才的命令,可以得到比较好的结果了:

分析结果

SwiftLint提供的Report文件内部的描述很清晰,不过再分析结果之前,我希望先生成一份文档来看看所有的规则。

生成文档

运行“swiftlint generate-docs”,会生成一个名为“rule_docs”的文档目录:

对照Report文件,来一条一条看下SwiftLint都给我们挑了什么错。

 

SwiftLint看了我们写的代码,大喝一声,说我们:

Tuples should have at most 2 members. - 每个元组(Tuple)类型最多有两个变量。
我们毕恭毕敬地搜索到了“large_tuple.md”这个规则,打开一看:

原来元组类型的推荐是两个变量以下,再多的,建议你封装成类了。

Unused parameter "row" in a closure should be replaced with _. - 有一个“row”变量没有被使用,用不着的变量声明为“_”。

Variable name should be between 4 and 40 characters long: 'vc'. - 有一个“row”变量的名字太短了,应该在4-40字符之间。

...

等等,等等。

通过Report文件的分析结果,可以更好的修正我们工程项目中的代码错误。

以上就是静态分析的基本使用。