SwiftLint

去年（2018）年末的時候，在 Twitter 上看到一些朋友們在討論著 SwiftLint 的使用，於是便也嘗試在目前公司的專案中導入，來解決 Coding Style 的問題。

Coding Style 的問題

剛進入到這家公司時，最痛苦的事情莫過於毫無章法的 Coding Style，這部分就不一一細數了，詳情可以看前陣子我的 Twitter 動態。

專案裡頭每個人寫的格式不同，會造成其他人在閱讀專案時，大幅增加理解彼此想法的成本

簡單來說就是浪費一堆時間在猜你在寫什麼

為了讓專案裡頭的大家有差不多的 Coding Style，可以選擇使用 SwiftLint 來處理這個情況。

首先先以 SwiftLint 的官方教學來安裝和建構環境，並利用 Ethan 的 SwiftLint rules 當作基底來調整，先以別人的規範來看看差異性。

一跑下去便是直接噴了 3000+ issues⋯⋯

可以透過 Rules.md 來逐條看看定義並透過 example 來看怎麼算是 Non Trggering 和 Triggering；再來一條一條調整改進。

目前公司的專案從 3000+ ➡️ 17 warings，而這 17 條是我還沒 refactor 到的 features，所以就還沒那麼急著去調整。

而其中一條規則 private_outlet 給我的感觸挺深刻的，由於我大多數的工作經歷是獨立開發居多，而每個 IBOutlet 都必須為 private 是第一份工作時所踩到的坑；當時公司共有兩位 iOS 工程師，彼此皆為 Junior 的程度，故沒什麼規範和概念，於是便會出現一些神秘的情境⋯⋯

像是不知道為什麼你負責的 UIViewController 刻出來的畫面就是和你想的不太一樣，才發現另一個地方（別人寫的 code）在直接修改畫面的 Layout / value⋯⋯

後來就體會到物件的每個變數和 functions 的 access 問題，而這條規則便是解釋著 IBOutlet 不應該可以直接從其他地方呼叫、修改，像是被這麼做：

fooViewController.fooLabel.text = "Test"

從那時候開始養成的習慣到現在，當發覺其實有其他人也是這麼做，並將它視為一條 rule 的時候真的覺得有點小感動！

你可以透過這個 SwiftLint 來反覆思考一些寫程式上的問題，像是 function 的長度、class 的長度以及 Swift 檔案的長度等；如何切割每個物件和 function 等，都是相當值得去思索的習慣問題。

不過也不需要逐條都導入到專案之中，建議是花一些時間找到你最認同的那幾條 rules 來遵循即可！