（一）什么是SwiftLint ？

SwiftLint.jpg

熟悉Python的同學(xué)一定對Pylint不會陌生，Pylint 是一個 Python 代碼分析工具，它分析 Python 代碼中的錯誤，查找不符合代碼風(fēng)格標(biāo)準(zhǔn)（Pylint 默認(rèn)使用的代碼風(fēng)格是 PEP 8，具體信息，請參閱參考資料）和有潛在問題的代碼。Python是一門很強調(diào)格式的語言，畢竟人家連大括號都沒有，反觀Swift，似乎不按照嚴(yán)格的規(guī)范編碼也沒有太大的問題？錯！寫出良好代碼風(fēng)格的代碼，可能比能否寫出高效的代碼更為重要。于是，SwiftLint就誕生了。SwiftLint是一個強制使用者按照Github的Swift編碼規(guī)范指南來開發(fā)的一種工具，它會將所有不符合Swift規(guī)范的代碼全部用warning標(biāo)注出來，一些嚴(yán)重的違背規(guī)則的代碼甚至讓它無法通過編譯（江山一片紅），想想是不是就很刺激呢？

（二）為什么需要Lint ？

1.獨行俠的困局

如果你是個人開發(fā)，或者說團隊沒有CodeReview，那么你的代碼絕對不是“完美”的。人總是會犯錯的，尤其是在高速的迭代和業(yè)務(wù)需求快速變更的時候，犯錯的幾率會成倍的增加。最讓人尷尬的是，Xcode是非常包容的，即使你的代碼不符合規(guī)范，但是如果語法是沒有問題的，那么它也會特別樂意的讓你通過編譯并且沒有任何的警告。

但是，但凡你是一個有追求的開發(fā)者，都會希望自己所寫出來的代碼，至少在代碼風(fēng)格上面無可挑剔。但是這又和現(xiàn)實世界的開發(fā)需求以及人性相矛盾，所以這就是一個困局。

2.CodeReview之殤

有幸，你所處在的公司是一個有技術(shù)追求的公司。那么，你們一定會有大量的互相Review。在我看來，CodeReview一般做這樣幾件事情：

• 代碼風(fēng)格規(guī)范統(tǒng)一
• 防止低效代碼、冗余代碼
• 防止出現(xiàn)可見的明顯BUG

第二第三點，其中富含了大量人腦的思考，屬于暫時還無法替代的操作（AI時代應(yīng)該可以）。但是第一點，實在屬于機械操作，就好像第一次工業(yè)革命的人工織布，是處在必然被淘汰的行列。

在這樣的時代浪潮之下，SwiftLint 應(yīng)運而生。

（三） 安裝

沒有辦法，按照技術(shù)文章的三板斧：安裝 - 使用 - 踩坑，這是怎么也繞不過去的一章。我相信讀者都聰慧無比，但是為了文章的完整性我還是要啰嗦幾句。

(1) 全局安裝

全局安裝就不得不提到我們的老朋友HomeBrew了，如果你沒有安裝，那么請看這里。

全局安裝非常簡單,首先我們需要通過brew命令安裝SwiftLint:

brew install swiftlint

然后添加編譯腳本：

全局安裝步驟圖.png

最后在黑框框中添加如下腳本:

if which swiftlint >/dev/null; then
  swiftlint
else
  echo "warning: SwiftLint not installed, download from https://github.com/realm/SwiftLint"
fi

即

Script.png

OK，大功告成，就可以編譯啦，之后每次安裝只需要給工程添加腳本就可以了。

(2) 局部安裝

除了全局安裝，我們也可以通過CocoaPods進行安裝。在Podfile上添加相關(guān)的依賴:

pod 'SwiftLint'

然后跟全局方法一樣，在Run Script中添加命令，但是內(nèi)容有些許的不同:

"${PODS_ROOT}/SwiftLint/swiftlint"

局部安裝.png

OK,接下來就讓我們來試試看SwiftLint吧！

（三）使用

在給項目初次接入SwiftLint的時候，你可能會被下面這樣的情景給嚇到：

瘋狂Warning和Error.png

但是呢，不用慌，我們可以看一下這是什么情況。仔細(xì)觀察一番之后，我們會發(fā)現(xiàn)，絕大多數(shù)的Warning都是這個原因：

image.png

WTF？我這一行哪里有空格符？簡直就是冤枉啊！但其實是這樣的，雖然看起來好像沒有空格符，但是在換行符之間不應(yīng)該摻雜制表符，也就是說你實際的代碼是這樣的:

\n \tab \n

所以呢，人家的Warning也不是沒有道理的嘛。那么我們該怎么來消除這些Warning呢？

首先，我們要確保，以后我們所碼的代碼不再出現(xiàn)這樣的格式，所以我們需要把Text Editing里面的Including whitespace-only lines勾選上:

image.png

這樣可以保證我們今后的換行不再出現(xiàn)制表符的警告，然后，我們就需要處理現(xiàn)有的代碼?，F(xiàn)有的代碼，少說也有幾萬行，手動改不是要累死人？這個時候就輪到SwiftLint的命令行出場了：

image.png

我們將目錄切換到工程的根目錄之下，然后敲擊如下命令:

swiftlint autocorrect

然后我們就會發(fā)現(xiàn)，所有的空格符Warning都消失了。這都得益于我們剛剛所進行的命令行操作，它會將已知的能夠自動修復(fù)的Error和Warning都自動修復(fù)，大大的減輕了我們的工作量。

但是又出現(xiàn)了一個問題，在項目的根目錄之下執(zhí)行自動糾正，SwiftLint會將Pods文件夾中的Swift文件也一起糾正了，第三方的框架原則上能不動就不動，那么我們該怎么辦呢？

這個時候就需要.swiftlint.yml文件了。那么這是一個什么文件呢？在使用SwiftLint的時候，很多時候我們會碰到一些自定義的規(guī)則需求，這個時候就需要.swiftlint.yml來解決問題了。

.swiftlint.yml

所謂的.swiftlint.yml其實就是SwiftLint的一個配置文件，我們可以通過這個配置文件來修改約束的規(guī)則，以此達到自定義的效果。

一般的配置文件大概長這個樣子:

image.png

下面我們來認(rèn)識一下主要的幾個配置選項,在此之前我們先要了解一下SwiftLint中的一個概念rules,所謂的rules就是一個一個的風(fēng)格規(guī)則，比如冒號的規(guī)則，空格符的規(guī)則，類型名的規(guī)則等等。截止目前，SwiftLint一共支持75種規(guī)則，如果你感興趣，可以在Source/SwiftLintFramework/Rules 中看到所有規(guī)則的實現(xiàn)。或者你也可以在終端輸入swiftlint rules來查看當(dāng)前的規(guī)則信息。

disabled_rules

disabled_rules: # 禁用指定的規(guī)則
  - file_length
  - ...

opt_in_rules

opt_in_rules: # 啟用指定的規(guī)則
  - file_length
  - ...

whitelist_rules

whitelist_rules: # 規(guī)則的白名單，但是不能和上面兩個規(guī)則一起使用
  - file_length 
  - ...

included

included: # 你所希望Lint檢索的路徑，SwiftLint會掃描該路徑下的所有.swift后綴的文件
  - ../

excluded

excluded: # 你所希望不要檢索的路徑,SwiftLint會無視掉該路徑下的文件
  - Pods

風(fēng)格規(guī)則

由于風(fēng)格規(guī)則太多了，這里不一一列舉，但是用法都是大致相同的：

force_cast: [warning | error] 當(dāng)出現(xiàn)強制類型轉(zhuǎn)換的時候是提示Error還是Warning

type_body_length:
  - 300 # 當(dāng)超過300行的時候飚黃
  - 400 # 當(dāng)超過400行的時候飚紅

** 還有很多的規(guī)則，用法大致相同，讀者如此聰慧，老夫不必多言。 **

注釋控制

還有一個場景，有的時候，我們并不想大范圍的禁用掉一個規(guī)則，但是在某個文件中，我們必須要無視這條規(guī)則，那么我們應(yīng)該怎么告訴SwiftLint來無視掉它呢？

** 很簡單，注釋！**

比如以下這種情況:

image.png

哇，這個是系統(tǒng)給的代理方法啊，竟然還警告我方法名稱過長！難道無視他？不行，強迫癥患者忍受不了?。?/p>

于是我們可以這樣:

image.png

OK,這樣在// swiftlint:disable line_length注釋之后的所有行長的警告都會被忽略掉。如果你想要在忽略掉這一行之后再次啟用，那么只要再添加一行// swiftlint:enable line_length就可以了。

image.png

如果你覺得，有很多的控制注釋也看起來不順眼的話，個人推薦可以這樣，把它寫在開頭的注釋上：

image.png

或者更加的極端：

image.png

配置文件的嵌套

值得一提的是，在我們使用配置文件的時候，SwiftLint會默認(rèn)將所指定的文件目錄遞歸的掃描下去的。如果掃描過程中，在子目錄下發(fā)現(xiàn)了一個新的.swiftlint.yml文件，那么子目錄下的規(guī)則就會改為新的配置規(guī)則。聽起來很實用，但是本人還沒用過??。

（四）踩坑

在本人使用該Lint的這段時間中，發(fā)現(xiàn)有兩個使用麻煩的地方，分享出來。

一號建議

注釋控制在實際的使用中非常的常用，所以強烈建議使用代碼塊來簡化操作：

image.png

二號建議

在實際的使用中，.swiftlint.yml的創(chuàng)建也是非常頻繁的，尤其是如果你是通過模塊化的開發(fā)，那么每當(dāng)新建一個模塊或者給一個模塊添加Lint的時候，你就需要創(chuàng)建至少一個YML文件，所以個人建議可以給SwiftLint添加一個輔助的命令行。

我使用Swift簡單實現(xiàn)了一個Maker,將其編譯之后的二進制可執(zhí)行文件拷貝到/usr/local/bin之后就可以使用了。

image.png

之后我們通過下面的命令就可以快速的創(chuàng)建一個YML文件，我們只需要在模板文件的基礎(chǔ)上進行修改就可以了:

maker -y

image.png

image.png

編譯方法

有同學(xué)說，不知道怎么使用Maker,這里簡單介紹一下，其實發(fā)布APP類似：

1.Xcode編譯方案

首先我們打開Maker工程，然后點擊Archive（簽名的事情自己搞定?。?/p>

image.png

稍等片刻，我們的程序就編譯完成了，然后步驟如下：

image.png

image.png

image.png

image.png

最后只需要兩句命令：

image.png

2.命令行編譯方案

第二種方法直接通過純命令的方式,更加簡單：

cd path # 這里的path是指main.swift所在的文件目錄之下
swiftc main.swift Maker.swift -o Maker # 編譯生成二進制文件
cp Maker /usr/local/bin # 復(fù)制到目標(biāo)目錄之下

OK！ 大功告成！ 快試試Maker吧！

這樣對我這種記性不太好的人來說就友好了許多o(￣▽￣)ｄ，其實講道理應(yīng)該發(fā)布HomeBrew之類的地方更加方便，但是功能太簡單不好意思，就隨便搞了搞，以后加了其他功能可能會考慮。

順便說一嘴，在Xcode插件被禁用之后，很多好用的功能都離我們遠(yuǎn)去了，但是這并不是意味著工作效率的降低。比如上述的命令行工具，更多的旨在拋磚引玉，主旨都是為了加快我們的開發(fā)效率，所以不要再只把Swift當(dāng)做iOS開發(fā)語言了哦！

Ending

由此可見，SwiftLint 使用起來對于開發(fā)者也是比較有好的。但凡是一個有代碼潔癖的iOS程序員，都可以來試試這個SwiftLint,我相信你絕對不會后悔了。在漫長的求職路上，我希望你不要因為代碼風(fēng)格問題被面試刷掉。

最后的最后，祝愿世界上所有的代碼都能如詩般優(yōu)雅整潔??。