《Python高手之路（第3版）》——1.4 編碼風格與自動檢查

本節書摘來自異步社群《python高手之路（第3版）》一書中的第1章，第1.4節，作者［法］julien danjou，王飛龍 譯，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

沒錯，編碼風格是一個不太讨巧的話題，不過這裡仍然要聊一下。

python具有其他語言少有的絕佳品質：使用縮進來定義代碼塊。乍一看，似乎它解決了一個由來已久的“往哪裡放大括号？”的問題，然而，它又帶來了“如何縮進？”這個新問題。

每個縮進層級使用4個空格。

每行最多79個字元。

頂層的函數或類的定義之間空兩行。

采用ascii或utf-8編碼檔案。

在檔案頂端，注釋和文檔說明之下，每行每條import語句隻導入一個子產品，同時要按标準庫、第三方庫和本地庫的導入順序進行分組。

在小括号、中括号、大括号之間或者逗号之前沒有額外的空格。

類的命名采用駱駝命名法，如camelcase；異常的定義使用error字首（如适用的話）；函數的命名使用下劃線分隔的小寫字母，如separated_by_underscores；用下劃線開頭定義私有的屬性或方法，如_private。

這些規範其實很容易遵守，而且實際上很合理。大部分程式員在按照這些規範寫代碼時并沒有什麼不便。

示例1.1　運作pep8

pep8會顯示在哪行哪裡違反了pep 8，并為每個問題給出其錯誤碼。如果違反了那些必須遵守的規範，則會報出錯誤（以e開頭的錯誤碼），如果是細小的問題則會報警告（以w開頭的錯誤碼）。跟在字母後面的3位數字則指出具體的錯誤或警告，可以從錯誤碼的百位數看出問題的大概類别。例如，以e2開頭的錯誤通常與空格有關，以e3開頭的錯誤則與空行有關，而以w6開頭的警告則表明使用了已廢棄的功能。

社群仍然在争論對并非标準庫一部分的代碼進行pep 8驗證是否是一種好的實踐。這裡建議還是考慮一下，最好能定期用pep 8驗證工具對代碼進行檢測。一種簡單的方式就是将其內建到測試套件中。盡管這似乎有點兒極端，但這能保證代碼一直遵守pep 8規範。8.7節中将介紹如何将pep8與tox內建，進而讓這些檢查自動化。

openstack項目從一開始就通過自動檢查強制遵守pep 8規範。盡管有時候這讓新手比較抓狂，但這讓整個代碼庫的每一部分都保持一緻，要知道現在它有167萬行代碼。對于任何規模的項目這都是非常重要的，因為即使對于空白字元的順序，不同的程式員也會有不同的意見。

也可以使用--ignore選項忽略某些特定的錯誤或警告，如示例1.2所示。

示例1.2　運作pep8時指定<code>--ignore</code>選項

這可以有效地忽略那些不想遵循的pep 8标準。如果使用pep8對已有的代碼庫進行檢查，這也可以暫時忽略某些問題，進而每次隻專注解決一類問題。

注意

還有一些其他的工具能夠檢查真正的編碼錯誤而非風格問題。下面是一些比較知名的工具。

這些工具都是利用靜态分析技術，也就是說，解析代碼并分析代碼而無需運作。

如果你正開始一個新項目，這裡強烈建議使用上述工具之一對代碼的品質和風格進行自動檢查。如果已經有了代碼庫，那麼一種比較好的方式是先關閉大部分警告，然後每次隻解決一類問題。

盡管沒有一種工具能夠完美地滿足每個項目或者每個人的喜好，但flake8和hacking的結合使用是持續改進代碼品質的良好方式。要是沒想好其他的，那麼這是一個向此目标前進的好的開始。

提示

這個工具集很容易擴充。我在openstack中用hacking擴充來擴充這個工具集，例如，我添加了一個檢查，用于找出本應該聲明為靜态的方法。這部分内容會在11.1節中談及。