922
Python
如何落實 Python 代碼風格？
作者：ipfans
來源：https://ipfans.github.io/2016/01/how-we-follow-python-style-guide/index.html
我們是如何落實 Code Style Guide 的（Python 篇）
最近年終，總是想談談過去一年的感悟和積累。接下來大概有幾篇關於項目管理等等一些小方麵的介紹，這篇文章主要介紹一下我們如何將 Python 編碼規範真正落實到程序的實際開發過程中的。
編碼規範選擇
Python 作為靈活的腳本語言，在格式方麵並不存在太多的限製（相對編譯語言）。這樣會導致一個比較蛋疼的問題：在項目開發過程中，由於個人的習慣和編碼風格，導致程序缺少一個統一的標準，每個人的代碼表現形式也不同。因此，在實際項目由於新人加入、老人退出過程中會產生比較高的模塊維護成本。因此，在實際的項目開發中，選擇一個編碼標準也是比較重要的。
麵對編碼風格選擇，比較常見的包括 PEP-8 和 Google Python Style Guide。在最後，我選擇了 作為項目中的實際應用標準，要求程序需要在滿足編碼要求規範的前提下進行編碼。
除了對代碼編碼更個的要求以外，我們還對 import 等具體的細節進行了標準化。
盡量規範注釋
在降低模塊維護成本過程中，另外一個比較好的方式是盡量提供良好的代碼注釋。盡管這個算是一個和語言無關的老生常談的問題，我隻是想在這裏提一下另外一個 PEP：PEP-0257，這裏介紹了一種約定的 docstring 編寫方法，對於編輯器而言，可以通過插件快速實現注釋。
不過我考慮到對個人習慣的影響較大，這個 PEP 實際項目開發中並未作為實際開發規範，隻是鼓勵大家在項目中進行執行。
從規範到執行
從代碼開發最初的規範約定是一回事，當回到開發過程中，開發者難免會因為個人的習慣或者疏忽等各種原因導致程序開發過程中程序編碼風格不統一問題。因此在實際開發過程中，我們又需要通過工具保證程序在實際過程中能夠幫助規範化或者檢查格式錯誤。
借助社區的力量，我們最終選擇了工具 、 和 。其中， 用於檢查我們的代碼是否正確的執行了標準； 工具用於快速進行 標準化，減少了人工修改的成本； 工具則是執行我們之前提到的 import 標準化工作。
是 Google 員工開發的一個 Python 格式化工具，它支持 PEP8 與 Google 編碼標準，一些具體的使用方式可以查看項目的主頁。在實際的項目落地過程中，你應該會遇到的一個問題是關於 與 標準不一致導致一個通過另一個無法正常通過的問題。這一個方麵，我們選擇的方式是統一妥協成 的標準。對於 不支持的部分，我們建議活用 標記。
還有另一個問題是關於一些 本身的標準（或者說 PEP－8 標準）問題，比如 常見問題： 程序代碼長度超過 79 個字符問題，我們實際編碼過程中對這一標準做了適當妥協，允許最大單行字符串長度為 200。但是我們仍然建議縮小至 79 個字符內表示完。
從執行到檢查
在最後一關，是我們的上線前檢查。我們設置了代碼質量檢查關卡和係統集成測試。
在代碼質量檢查過程中，我們會對程序的實際代碼質量進行評估。我們對代碼質量進行打分，對於分值較低的代碼不允許提交進入 分支。代碼質量的檢查，我們同樣的采用了 工具作為統一標準。最後個人的代碼質量，通過 Webhook 也會直接反饋在具體的項目管理工具中。
題圖：pexels，CC0 授權。
最後更新：2017-10-08 23:49:38