一直以來，關於“程式碼規範”的話題都備受關注，業界甚至有很多流傳甚廣的段子不斷調侃之。既然程式碼規範能引起這麼大的共鳴，那麼今天我們談談一個程式設計師的自我修養——如何寫出優雅的程式碼？

Martin（Bob大叔）曾在《程式碼整潔之道》一書中說：當你的程式碼在做 Code Review 時，審查者要是憤怒地吼道：“What the fuck, is this shit?”、“Dude, What the fuck！”等言辭激烈的詞語，那說明你寫的程式碼是 Bad Code，如果審查者只是漫不經心的吐出幾個：“What the fuck?”，那說明你寫的是 Good Code。

衡量程式碼質量的唯一標準就是每分鐘罵出“WTF”的頻率。

程式碼不規範會有哪些痛點？

影響團隊合作，降低效率。對於共同完成專案的團隊而言，如果沒有統一的程式碼規範，最終整合程式碼時可能會出現看不懂命名或者閱讀過程不斷詢問的情況，導致團隊效率低下，甚至造成成員之間的矛盾。例如 git push -f，把別人的勞動成果全部覆蓋掉，出現一次就會遭到全員圍攻，豬隊友啊......

提高維護成本。程式碼不規範導致可讀性降低，後期的程式碼維護會耗費更多人力甚至財力成本.一旦程式碼越來越多，最後的維護就難以為繼，會給運維人員造成很大負擔。

引發各種 bug。如果輸入輸出引數、異常處理、日誌處理等沒有規範，很容易導致大量低階 bug，還很難找到 bug 的原因。

不利於程式碼審查，甚至造成安全漏洞。程式碼審查是糾正程式碼錯誤，保證開發週期安全順利進行的重要一步。如果程式碼不規範，就會加重程式碼審查的工作量和難度，導致程式碼審查工作沒有根據還浪費時間。某些情況下，程式碼不規範還會造成安全漏洞，此前 Morpheus 智慧合約爆出的重大安全漏洞，就是大小寫錯誤造成的。

不利於程式設計師自身的成長。有些人可能沒有意識到程式碼規範的重要性，有些人意識到了但由於專案時間緊、流程繁瑣等原因而不去遵循。這跟當前開發流程與安全之間的關係很像。很多人為了速度而犧牲前期的必要流程，卻給後續的工作帶來了更多麻煩。其實，規範的程式碼有助於理解開發語言、模式和架構，也有利於提升開發水平。

X，哪個蠢貨寫的程式碼！一看註釋，author是自己......如果你發現你之前的程式碼很low，說明你已經進步了。那麼如何寫出優雅的程式碼？

如何寫出優雅的程式碼？

1、採用規範

每種語言都有自己的推薦風格，如Swfit最近有Google Swift Style Guide，顯然OC與Swift有著不同的風格。當我們開始寫Swift，首先要注意的就是按照Swift的風格寫，而不是沿用OC的風格，組內應該形成一種公認統一風格以便於後期維護。

從規範目標細節的角度，程式碼規範分為：

註釋、命名、縮排空格、語句格式、規模、可靠性、語言特殊項。

2、Code Review

一份優雅、乾淨、整潔的程式碼通常自帶文件和註釋屬性，讀程式碼即是讀作者的思路。我們在Review的過程中會發現很多不夠優雅的程式碼，命名不規範者or影響效能，甚至存在致命bug。那麼如何在團隊內推行Code Review呢？我分享下我們組內目前採用的形式。

我們團隊內部採用Gitlab工具，在開始一個新的迭代後，每個同事為自己負責的模組建立一個獨立分支，各自在自己獨立的分支完成開發，功能開發完成後，在Gitlab提交Merge Request，如果與其他同事模組有依賴，或者業務較為複雜，可分為小的功能點多次提交；負責Code Review同事Review的時候應該先讓提交者講一下大概設計的思路，在GitLab中指出存在優化的點，待提交者修改完畢後再將該分支合入主幹分支。

引入Code Review的機制在一定程度上可以提升團隊內程式碼質量，也可以減少低階bug的出現，對組內交叉熟悉彼此業務也有好處。

3、Code Lint

可能儘管我們推行了統一的程式碼規範，也進行了CodeReview，我們會發現只要團隊成員足夠多，每位成員都有不同的背景，純靠人肉難免依然有不規範的程式碼存在，那麼這個時候就應該採用Code Lint了。每種語言應該都有自己的編譯器對應的外掛，以iOS為例有SwiftLint 、ocLint，這裡我簡單介紹下我們團隊內部使用的SwiftLint。

SwiftLint可以看作是一個Xcode外掛，基於Sourcekit & Clang AST的應用（Sourcekit & Clang AST這裡不做過多介紹），通過語法規範檢查，可以在編譯期將所有不符合Swift規範的程式碼全部用warning標註出來，一些嚴重的違背規則的程式碼甚至讓它無法通過編譯（萬里江山一片黃）。

SwiftLint安裝很方便，Homebrew brew install swiftlint即可安裝好，然後為Xcode新增Run Script Phase。

接下來編譯，就可以看到99+ warning（如下圖所示）。請不要驚慌，我們可以使用swiftlint autocorrect自動解決部分警告，也可以通過.swiftlint.yml配置符合團隊規範的規則，通過編譯器檢查規範比人肉檢查更加準確高效細緻，團隊內部也可以做到高度統一的 Code Style。

4、閱讀學習交流分享

總結絕大多數開發者的日常，對新功能開發的迫切遠遠大於重構一箇舊的功能，導致很多程式碼都沒有很好的版本迭代。慢慢的，破舊、破損的模組讓人覺得似乎無人照管，於是別人也不再關心，最終自己也參與破壞活動，走上一條打補丁的不歸路。

其實從一開始，我們就應該抱著一種重視自己的程式碼的態度來寫程式碼，而不是想著先完成功能，以後再來重構優化，程式碼如生活：稍後就等於永不。如何保持程式碼整潔，離不開設計模式和程式碼重構，多閱讀開源社群的程式碼，比如最近微信開源的MMKV就可以讀來學習，像世界同行大佬學習交流如何優雅的寫程式碼，也可以讀一些經典的書籍如《程式碼整潔之道》、《重構改善既有程式碼的設計》、《重構改善既有程式碼的設計》等等。