Python編碼規範的重要性

很多去 Google 參觀的人，在用完洗手間後都有這樣的疑惑，馬桶前面的門上怎麼會貼著 Python 編碼規範？要知道，Google 對編碼規範的要求極其嚴格，這也能從側面說明編碼規範的重要性。

對於編碼規範的認知，很多初學者還僅停留在初級階段，即只知道編碼規範有用，比如命名時使用駝峰式的格式（如 TheFirstDemo），而至於為什麼要求這樣嚴格，就不是很清楚了。

本節，將給讀者掃除以下 2 個盲區：

1. Python 編碼規範到底有多麼重要，它對於業務開發來說，究竟有哪些幫助？
2. 有哪些流程和工具，可以強制你遵循規定好的編碼規範呢？

注意，在講解過程，會參照以下 2 個編碼規範來舉例，分別是：

• 《8 號 Python 增強規範》，通常稱之為 PEP8；
• 《Google Python 風格規範》 簡稱為 Google Style，這是源自 Google 內部公開發布的社群版本，其目的是為了讓 Google 旗下所有 Python 開源專案的程式設計風格統一。

以上這 2 個編碼規範，Google Style 比 PEP8 更為嚴格，因為 PEP8 的主要面向群體是個人和小團隊開發者，而 Google Style 則能夠勝任大團隊甚至是企業。

Python編碼規範到底有多麼重要

Python 編碼規範重要性的原因用一句話來概括就是：統一的編碼規範可以提高開發效率。

而影響開發效率的有 3 類物件，分別是閱讀者、程式設計者和機器，它們的優先順序是閱讀者>>程式設計者>>機器（>>表示遠遠大於）。

閱讀者>>程式設計者

寫過程式碼的人應該深有體會，在實際工作中真正用來碼程式碼的時間，遠比閱讀或者偵錯的時間要少。事實也是如此，有研究表明，軟體工程中 80% 的時間都在閱讀程式碼。

因此，如果想提高開發效率，首先要優化的不是碼程式碼的速度，而是閱讀程式碼的體驗。

其實，很多編碼規範本身就是為優化讀者體驗而存在的，拿命名原則來說，PEP8 第 38 條規定命名不能是無意義的單字母，有意義的名稱可以很大程式提高閱讀者的體驗。

程式設計者>>機器

說完了閱讀者的體驗，再來聊聊程式設計者的體驗。筆者常常見到的一個錯誤傾向就是過度簡化自己的程式碼，這樣做會大大降低程式碼的可閱讀性，並且一旦出現 BUG，也不容易檢查出來。

例如，閱讀如下這行程式：

result = [(x, y) for x in range(10) for y in range(5) if x * y > 10]

上面這行程式碼還可以改寫成如下這種形式：

result = []
for x in range(10):
  for y in range(5):
     if x * y > 10:
       result.append((x, y))

以上程式碼，涉及到了列表和判斷迴圈結構的相關知識，由於還未學到，初學者不需要理解。

對比這 2 種寫法，顯然後者調理更清楚，更容易理解，編寫起來也更輕鬆。

機器體驗也很重要

每個人都希望自己編寫的程式碼能正確、高效地在電腦上執行，但是一些危險的程式設計風格，不僅會影響程式的正確性，也容易成為程式碼效率的瓶頸。

例如，PEP8 和 Google Style 都特別強調了，何時使用 is， 何時使用 ==，何時使用隱式布林轉換。不僅如此，Google Style 2.8 還對遍歷方式的選擇作出了明確限制。

在程式設計過程中，只要嚴格遵守編碼規範，編寫出的程式碼通常都很健壯，可移植性也很高。

編碼規範的自動化工具

既然編碼規範的終極目標是提高開發效率。所以，如果每次寫程式碼都需要在程式碼規範上額外花很多時間，就達不到我們的初衷了。

首先，你需要根據自己的具體工作環境，選擇或者制定適合自己公司或團隊的編碼規範。市面上可以參考的規範，也就是在文章開頭提到的 PEP8 和 Google Style。

要知道，沒有放之四海而皆準的規範，我們必須要因地制宜。例如在 Google 中，因為歷史原因 C++ 不使用異常，引入異常對整個程式碼庫帶來的風險已經遠大於它的益處，所以在它的 C++ 程式碼規範中，禁止使用異常。

一旦確定了整個團隊所遵從的編碼規範，就一定要強制執行，有什麼好的辦法呢？靠強制程式碼評審和強制靜態或者動態 linter。具體流程是：

1. 在程式碼評審工具裡，新增必須的編碼規範環節；
2. 把團隊確定的程式碼規範寫進 Pylint 裡，能夠在每份程式碼提交前自動檢查，不通過的程式碼無法提交。

整合之後，你的團隊工作流程就會變成圖 1 所示的這樣。

---