写在前面的话
最近有点发懒筋很长没有计划，没有时间，来更新这里的文章。
这篇文章会简略的写一下SwiftLint的使用流程。
其实是沉迷打CSGO，咳咳。
枪打的不咋地，饰品倒是买了一大堆。
静态分析
之前在学习iOS开发高手课的时候，曾经被又被重新科普了一遍“静态分析”的作用与使用方法。
静态分析，依据我自己的理解，基本是通过全量扫描的形式，来发现一些代码上的错误：
- 格式是否正确，有没有声明类的时候左右有没有多一个空格，少一个空格；
- 变量命名是否正确，有没有一会用下划线命名法，一会用驼峰命名法；
- 是否对显而易见的空类型进行了强制解包操作；
- ...
一些通过字符串分析能找到的错误，都可以用静态分析来解决。
而其中SwiftLint，OCLint是比较常用的工具。
那让我们来实践一下，静态分析，都能找出些什么？
SwiftLint
最近才知道SwiftLint是Realm团队开发的工具，Realm就是那个和对标CoreData的跨平台数据库管理方案。
曾经使用过一次，但是后续的项目中都没有嵌入这么一个编译很慢的庞然大物的必要，所以已经很久没有接触了。
SwiftLint的项目地址在这里。
它的安装有好几种方式，我们选择最常用的HomeBrew的方式即可。
常用命令
记住以下几个常用命令就足够了：
|
1 2 3 4 5 |
// 分析并输出到指定文件 swiftlint lint --reporter html>swiftlint.html // 生成规则文档 swiftlint generate-docs |
先用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文件的分析结果，可以更好的修正我们工程项目中的代码错误。
以上就是静态分析的基本使用。
评论