我們是如何落實Code Style Guide的（Python篇）

我們是如何落實Code Style Guide的（Python篇）

最近年終，總是想談談過去一年的感悟和積累。接下來大概有幾篇關于項目管理等等一些小方面的介紹，這篇文章主要介紹一下我們如何將Python編碼規范真正落實到程序的實際開發過程中的。

編碼規范選擇

Python作為靈活的腳本語言，在格式方面并不存在太多的限制（相對編譯語言）。這樣會導致一個比較蛋疼的問題：在項目開發過程中，由于個人的習慣和編碼風格，導致程序缺少一個統一的標準，每個人的代碼表現形式也不同。因此，在實際項目由于新人加入、老人退出過程中會產生比較高的模塊維護成本。因此，在實際的項目開發中，選擇一個編碼標準也是比較重要的。

面對編碼風格選擇，比較常見的包括 PEP-8 和 Google Python Style Guide 。在最后，我選擇了 PEP-8 作為項目中的實際應用標準，要求程序需要在滿足編碼要求規范的前提下進行編碼。

除了對代碼編碼更個的要求以外，我們還對import等具體的細節進行了標準化。

盡量規范注釋

在降低模塊維護成本過程中，另外一個比較好的方式是盡量提供良好的代碼注釋。盡管這個算是一個和語言無關的老生常談的問題，我只是想在這里提一下另外一個PEP： PEP-0257 ，這里介紹了一種約定的docstring編寫方法，對于編輯器而言，可以通過插件快速實現注釋。

不過我考慮到對個人習慣的影響較大，這個PEP實際項目開發中并未作為實際開發規范，只是鼓勵大家在項目中進行執行。

從規范到執行

從代碼開發最初的規范約定是一回事，當回到開發過程中，開發者難免會因為個人的習慣或者疏忽等各種原因導致程序開發過程中程序編碼風格不統一問題。因此在實際開發過程中，我們又需要通過工具保證程序在實際過程中能夠幫助規范化或者檢查格式錯誤。

借助社區的力量，我們最終選擇了工具 flake8 、 yapf 和 isort 。其中， flake8 用于檢查我們的代碼是否正確的執行了標準； yapf 工具用于快速進行 PEP-8 標準化，減少了人工修改的成本； isort 工具則是執行我們之前提到的import標準化工作。

yapf 是Google員工開發的一個Python格式化工具，它支持PEP8與Google編碼標準，一些具體的使用方式可以查看項目的主頁。在實際的項目落地過程中，你應該會遇到的一個問題是關于 flake8 與 yapf 標準不一致導致一個通過另一個無法正常通過的問題。這一個方面，我們選擇的方式是統一妥協成 flake8 的標準。對于 yapf 不支持的部分，我們建議活用 # yapf: disable 標記。

還有另一個問題是關于一些 flake8 本身的標準（或者說PEP－8標準）問題，比如 flake8 常見問題： E501 程序代碼長度超過79個字符問題，我們實際編碼過程中對這一標準做了適當妥協，允許最大單行字符串長度為200。但是我們仍然建議縮小至79個字符內表示完。

從執行到檢查

在最后一關，是我們的上線前檢查。我們設置了代碼質量檢查關卡和系統集成測試。

在代碼質量檢查過程中，我們會對程序的實際代碼質量進行評估。我們對代碼質量進行打分，對于分值較低的代碼不允許提交進入 master 分支。代碼質量的檢查，我們同樣的采用了 flake8 工具作為統一標準。最后個人的代碼質量，通過Webhook也會直接反饋在具體的項目管理工具中。