（一）什么是SwiftLint ？
熟悉Python的同学一定对Pylint不会陌生，Pylint 是一个 Python 代码分析工具，它分析 Python 代码中的错误，查找不符合代码风格标准（Pylint 默认使用的代码风格是 PEP 8，具体信息，请参阅参考资料）和有潜在问题的代码。Python是一门很强调格式的语言，毕竟人家连大括号都没有，反观Swift，似乎不按照严格的规范编码也没有太大的问题？错！写出良好代码风格的代码，可能比能否写出高效的代码更为重要。于是，SwiftLint就诞生了。SwiftLint是一个强制使用者按照Github的Swift编码规范指南来开发的一种工具，它会将所有不符合Swift规范的代码全部用warning标注出来，一些严重的违背规则的代码甚至让它无法通过编译（江山一片红），想想是不是就很刺激呢？
（二）为什么需要Lint ？
1.独行侠的困局
如果你是个人开发，或者说团队没有CodeReview，那么你的代码绝对不是“完美”的。人总是会犯错的，尤其是在高速的迭代和业务需求快速变更的时候，犯错的几率会成倍的增加。最让人尴尬的是，Xcode是非常包容的，即使你的代码不符合规范，但是如果语法是没有问题的，那么它也会特别乐意的让你通过编译并且没有任何的警告。
但是，但凡你是一个有追求的开发者，都会希望自己所写出来的代码，至少在代码风格上面无可挑剔。但是这又和现实世界的开发需求以及人性相矛盾，所以这就是一个困局。
2.CodeReview之殇
有幸，你所处在的公司是一个有技术追求的公司。那么，你们一定会有大量的互相Review。在我看来，CodeReview一般做这样几件事情：
- 代码风格规范统一
- 防止低效代码、冗余代码
- 防止出现可见的明显BUG
第二第三点，其中富含了大量人脑的思考，属于暂时还无法替代的操作（AI时代应该可以）。但是第一点，实在属于机械操作，就好像第一次工业革命的人工织布，是处在必然被淘汰的行列。
在这样的时代浪潮之下，SwiftLint 应运而生。
（三） 安装
没有办法，按照技术文章的三板斧：安装 - 使用 - 踩坑，这是怎么也绕不过去的一章。我相信读者都聪慧无比，但是为了文章的完整性我还是要啰嗦几句。
(1) 全局安装
全局安装就不得不提到我们的老朋友HomeBrew了，如果你没有安装，那么请看这里。
全局安装非常简单,首先我们需要通过brew命令安装SwiftLint:
brew install swiftlint
然后添加编译脚本：
最后在黑框框中添加如下脚本:
if which swiftlint >/dev/null; then
swiftlint
else
echo "warning: SwiftLint not installed, download from https://github.com/realm/SwiftLint"
fi
即
OK，大功告成，就可以编译啦，之后每次安装只需要给工程添加脚本就可以了。
(2) 局部安装
除了全局安装，我们也可以通过CocoaPods进行安装。在Podfile上添加相关的依赖:
pod 'SwiftLint'
然后跟全局方法一样，在Run Script中添加命令，但是内容有些许的不同:
"${PODS_ROOT}/SwiftLint/swiftlint"
OK,接下来就让我们来试试看SwiftLint吧！
（三）使用
在给项目初次接入SwiftLint的时候，你可能会被下面这样的情景给吓到：
但是呢，不用慌，我们可以看一下这是什么情况。仔细观察一番之后，我们会发现，绝大多数的Warning都是这个原因：
WTF？我这一行哪里有空格符？简直就是冤枉啊！但其实是这样的，虽然看起来好像没有空格符，但是在换行符之间不应该掺杂制表符，也就是说你实际的代码是这样的:
\n \tab \n
所以呢，人家的Warning也不是没有道理的嘛。那么我们该怎么来消除这些Warning呢？
首先，我们要确保，以后我们所码的代码不再出现这样的格式，所以我们需要把Text Editing里面的Including whitespace-only lines勾选上:
这样可以保证我们今后的换行不再出现制表符的警告，然后，我们就需要处理现有的代码。现有的代码，少说也有几万行，手动改不是要累死人？这个时候就轮到SwiftLint的命令行出场了：
我们将目录切换到工程的根目录之下，然后敲击如下命令:
swiftlint autocorrect
然后我们就会发现，所有的空格符Warning都消失了。这都得益于我们刚刚所进行的命令行操作，它会将已知的能够自动修复的Error和Warning都自动修复，大大的减轻了我们的工作量。
但是又出现了一个问题，在项目的根目录之下执行自动纠正，SwiftLint会将Pods文件夹中的Swift文件也一起纠正了，第三方的框架原则上能不动就不动，那么我们该怎么办呢？
这个时候就需要.swiftlint.yml文件了。那么这是一个什么文件呢？在使用SwiftLint的时候，很多时候我们会碰到一些自定义的规则需求，这个时候就需要.swiftlint.yml来解决问题了。
.swiftlint.yml
所谓的.swiftlint.yml其实就是SwiftLint的一个配置文件，我们可以通过这个配置文件来修改约束的规则，以此达到自定义的效果。
一般的配置文件大概长这个样子:
下面我们来认识一下主要的几个配置选项,在此之前我们先要了解一下SwiftLint中的一个概念rules,所谓的rules就是一个一个的风格规则，比如冒号的规则，空格符的规则，类型名的规则等等。截止目前，SwiftLint一共支持75种规则，如果你感兴趣，可以在Source/SwiftLintFramework/Rules 中看到所有规则的实现。或者你也可以在终端输入swiftlint rules来查看当前的规则信息。
disabled_rules
disabled_rules: # 禁用指定的规则
- file_length
- ...
opt_in_rules
opt_in_rules: # 启用指定的规则
- file_length
- ...
whitelist_rules
whitelist_rules: # 规则的白名单，但是不能和上面两个规则一起使用
- file_length
- ...
included
included: # 你所希望Lint检索的路径，SwiftLint会扫描该路径下的所有.swift后缀的文件
- ../
excluded
excluded: # 你所希望不要检索的路径,SwiftLint会无视掉该路径下的文件
- Pods
风格规则
由于风格规则太多了，这里不一一列举，但是用法都是大致相同的：
force_cast: [warning | error] 当出现强制类型转换的时候是提示Error还是Warning
type_body_length:
- 300 # 当超过300行的时候飚黄
- 400 # 当超过400行的时候飚红
** 还有很多的规则，用法大致相同，读者如此聪慧，老夫不必多言。 **
注释控制
还有一个场景，有的时候，我们并不想大范围的禁用掉一个规则，但是在某个文件中，我们必须要无视这条规则，那么我们应该怎么告诉SwiftLint来无视掉它呢？
** 很简单，注释！**
比如以下这种情况:
哇，这个是系统给的代理方法啊，竟然还警告我方法名称过长！难道无视他？不行，强迫症患者忍受不了啊！
于是我们可以这样:
OK,这样在// swiftlint:disable line_length注释之后的所有行长的警告都会被忽略掉。如果你想要在忽略掉这一行之后再次启用，那么只要再添加一行// swiftlint:enable line_length就可以了。
如果你觉得，有很多的控制注释也看起来不顺眼的话，个人推荐可以这样，把它写在开头的注释上：
或者更加的极端：
配置文件的嵌套
值得一提的是，在我们使用配置文件的时候，SwiftLint会默认将所指定的文件目录递归的扫描下去的。如果扫描过程中，在子目录下发现了一个新的.swiftlint.yml文件，那么子目录下的规则就会改为新的配置规则。听起来很实用，但是本人还没用过。
（四）踩坑
在本人使用该Lint的这段时间中，发现有两个使用麻烦的地方，分享出来。
一号建议
注释控制在实际的使用中非常的常用，所以强烈建议使用代码块来简化操作：
二号建议
在实际的使用中，.swiftlint.yml的创建也是非常频繁的，尤其是如果你是通过模块化的开发，那么每当新建一个模块或者给一个模块添加Lint的时候，你就需要创建至少一个YML文件，所以个人建议可以给SwiftLint添加一个辅助的命令行。
我使用Swift简单实现了一个Maker,将其编译之后的二进制可执行文件拷贝到/usr/local/bin之后就可以使用了。
之后我们通过下面的命令就可以快速的创建一个YML文件，我们只需要在模板文件的基础上进行修改就可以了:
maker -y
编译方法
有同学说，不知道怎么使用Maker,这里简单介绍一下，其实发布APP类似：
1.Xcode编译方案
首先我们打开Maker工程，然后点击Archive（签名的事情自己搞定啊）：
稍等片刻，我们的程序就编译完成了，然后步骤如下：
最后只需要两句命令：
2.命令行编译方案
第二种方法直接通过纯命令的方式,更加简单：
cd path # 这里的path是指main.swift所在的文件目录之下
swiftc main.swift Maker.swift -o Maker # 编译生成二进制文件
cp Maker /usr/local/bin # 复制到目标目录之下
OK！ 大功告成！ 快试试Maker吧！
这样对我这种记性不太好的人来说就友好了许多o(￣▽￣)ｄ，其实讲道理应该发布HomeBrew之类的地方更加方便，但是功能太简单不好意思，就随便搞了搞，以后加了其他功能可能会考虑。
顺便说一嘴，在Xcode插件被禁用之后，很多好用的功能都离我们远去了，但是这并不是意味着工作效率的降低。比如上述的命令行工具，更多的旨在抛砖引玉，主旨都是为了加快我们的开发效率，所以不要再只把Swift当做iOS开发语言了哦！
Ending
由此可见，SwiftLint 使用起来对于开发者也是比较有好的。但凡是一个有代码洁癖的iOS程序员，都可以来试试这个SwiftLint,我相信你绝对不会后悔了。在漫长的求职路上，我希望你不要因为代码风格问题被面试刷掉。
最后的最后，祝愿世界上所有的代码都能如诗般优雅整洁。