python程序設計規範

07-13

python程序設計規範

來自專欄研發技術博客8 人贊了文章

隨著產品版本迭代和日漸豐富的功能，源文件及代碼也愈發龐大和複雜，對於程序開發人員來說，除了保障程序運行的正確性及提升代碼運行的性能和效率之外，一套優雅統一的編碼規範會對項目的更新、修改、維護等帶來極大的便捷性，也能是程序免於陷入不同風格代碼理解的泥潭中而無法自拔(編碼規範的必要性可參考谷歌前計算機科學家 Mark Chu-Carroll的一篇短文，有興趣可以點擊去接受一次噴洗^-^ . http://goodmath.scientopia.org/2011/07/14/stuff-everyone-should-do-part-2-coding-standards/此處不過多深入)。結合過往多年的工作經驗，筆者下文從Python編碼規範、URL設計規範、程序設計常見注意事項三個方面進行了簡單闡述。

一、 Python編碼規範

Python編碼規範此處主要結合日常開發項目情況，根據常用的PEP8規範做了部分篩選和小結：

1. 代碼布局

縮進：四個空格；
空格or tab的選擇：用空格，在IDE中自動使用空格作為換行，如果自己在vim中編輯時，要用空格，保持一致；
最大行寬：所有行的最大行寬為79個字元，如果是文本（如注釋）最大為72字元；
空行：全局函數之間、類定義之間空兩行；成員方法之間空一行；
標準庫或者普通庫的導入：

①　導入一個庫在單獨行；

②　導入始終在文件的頂部，在模塊注釋和文檔字元串之後，在模塊全局變數和常量之前；

③　導入順序：標準庫,第三方庫，本地庫。導入之間要有空行；

④　盡量使用絕對路徑導入。

2. 表達式和語句中的空格

總體原則，避免不必要的空格；
各種右括弧前不要加空格；
逗號、冒號、分號前不要加空格；
函數的左括弧前不要加空格，如Func(1)；
序列的左括弧前不要加空格，如list[2]；
操作符左右各加一個空格，不要為了對齊增加空格；
函數默認參數使用的賦值符左右省略空格；
不要將多句語句寫在同一行，儘管使用『；』允許；
if/for/while語句中，即使執行語句只有一句，也必須另起一行。

3. 注釋

在更新代碼時，優先更新注釋，不對應的注釋比沒注釋還要糟糕；
類定義時需要說明類的用途；
除少部分無歧義方法（如__init__）外，一般函數方法需要說明函數的具體作用，函數的輸入參數，返回值類型及格式。

4. 命名約定

前面有單下劃線：1.弱內部標誌：from M import不會導入的對象；
後面有單下劃線：1.避免與關鍵字衝突；
前面有雙下劃線：1.對類這樣命名的時候，會觸發名字重整；
避免使用的名字：1.i,小寫i；2.I,大寫i；3.O,大寫o；
模塊名、包名：模塊名全部小寫，用下劃線連接；包名也是小寫，但是不用下劃線；
類名：CapWord命名，也就是pascal風格，首字母大寫；
異常名：在類名後添加Error；
全局變數名：變數盡量只用於模塊內部，約定類似函數。對設計為通過 "from M import " 來使用的模塊，應採用 all 機制來防止導入全局變數；或者為全局變數加一個前置下劃線；
函數名：小寫，必要時添加下劃線；
函數和方法參數：實例方法第一個參數是 self。類方法第一個參數是 cls；
常量命名：大寫字母加下劃線；
繼承命名：公開屬性應該沒有前導下劃線；
如果公開屬性名和保留關鍵字衝突，可以添加後置下劃線；
簡單的公開數據屬性，最好只公開屬性名，沒有複雜的訪問/修改方法，python的Property提供了很好的封裝方法。 d.如果不希望子類使用的屬性，考慮用兩個前置下劃線(沒有後置下劃線)命名。

5 編程中的建議

none值比較盡量用is，is not 而不是用==；
異常類繼承自Exception，而不是BaseException；
Python2中用"raise ValueError(message)"代替"raiseValueError, message"；
捕獲異常時盡量指明具體異常，而不是空"except:"子句；
函數或者方法在沒有返回時要明確返回None；
使用字元串方法而不是string模塊；
使用.startswith()和.endswith()代替字元串切片來檢查前綴和後綴；
使用isinstance()代替對象類型的比較：
對序列(字元串、列表、元組),空序列為false:
字元串後面不要有大量拖尾空格；
不要用== 進行布爾比較

二、設計URL應該遵循的原則

1、簡單，好記

簡單好記的域名會給人以深刻的印象。

2、URL中的字母全部用小寫

全部用小寫，用戶比較容易輸入，不用因為大小寫混合而出現錯誤，這是人們的輸入習慣，有些伺服器是區分大小寫的，例如Lunix伺服器，這樣在站長做鏈接或者是用戶輸入時，會因為大小寫的問題而出現404錯誤，而且robots也是區分大小寫的，如果大小寫搞錯了，可能會造成不能收錄的嚴重問題。所以建議所有的URL都使用小寫。

3、連詞符的使用

目錄或者文件名中如果有兩個單片語成時，一般建議中間使用中劃線(-)隔開，切記不要使用下劃線或者其他字元，在搜索引擎中，它是把中劃線當作一個空格來處理的，而下劃線則是被忽略的，例如seo-caipiao會被讀成seo與caipiao。這是比較友好的寫法。

4、URL中避免太多參數

設計的則是URL中的參數應該盡量減少，不要超過三個，一般的情況下URL中的參數2-3個就可以了。

5、目錄層次盡量少

這裡所指的目錄層次是指物理目錄結構，而不是指邏輯結構，我們在進行URL的設計時，網站的結構要盡量的去減少目錄層次，層次不能太深了，一般建議不要超過三層，特別對於一些新站來說，權重低，搜索引擎蜘蛛爬行得很淺，深一點的頁面，蜘蛛都很可能不會去爬行的，所以要盡量的做到使目錄層次減少，URL縮短。根據觀察，百度尤其比較喜歡目錄層次比較少的頁面。

6、文件名及目錄名要具描述性

文件名及目錄名要具有可描述性，不但讓用戶一眼就能看出來這個頁面是關於什麼的，對用戶體驗比較友好，而且搜索引擎也比較喜歡這樣的URL。

例如一個關於新聞的目錄，我們可以把它命名為news，用戶看到這個目錄名稱，大概就知道這個目錄是關於什麼內容的了。

7、URL應該呈現一個降級的次序

例如：域名/類型/分類/標題

例如：域名/年/月/日

http://domain.com/news/tech/2007/11/05/google-announces-android

三、程序設計注意事項：

1. 時效和性能

1.1 循環使用

在程序設計及功能實現的過程中，很多時候我們需要用到循環來是完成特定的業務需求，相應的在某些情況下該部分則可能引起該介面的性能問題；

在選擇循環設計的過程中，需要注意一些事項：

循環體中是否有db操作，http,tcp請求操作等和網路相關的耗時行為，若有，則盡量避免使用循環，使用其他替代方式實現相應功能；

如：查詢近期三十天內每日數據統計情況；

原始方式：

優化後：

需要插入大量多數據，盡量採用批量插入方式，避免使用循環；

如：

當某些情況下不得不使用循環，同時循環體中又不可避免有耗時的操作，如複雜演算法計算等，此時可採取多線程/多進程/微服務/非同步回調等方式。

1.2 遞歸使用

遞歸用法有些時候確實可能比較方便的實現一些特殊的業務邏輯，但同時隨之而來的也帶來了一些新的風險：無限遞歸, 由於代碼設計的不合理或者一些特殊情況的出現很有可能導致遞歸程序結束條件無法生效，難以跳出遞歸，程序徹底卡死或者延遲嚴重。

當必須使用遞歸用法時，有必要預估遞歸的極限次數，做好相應的防範錯誤，如當遞歸到一定次數閾值時，強制跳出遞歸，輸出錯誤日誌。

2. 耦合性

程序開發過程中，代碼各模塊之間的耦合性高低很多時候將決定著代碼質量的好壞以及後續維護和擴展的易用性；在日常架構設計時，我們需要盡量去解耦不同的功能和邏輯模塊，最大程度降低相互之間的直接依賴性；不同模塊間互相不關注其內部細節，定義好介面後自身封裝相應內部邏輯，無論內部如何變化使其不影響其他模塊的外部調用者。

如筆者當前一個小項目中所使用的架構：

3. 擴展性

代碼的低耦合性很大程度上也決定了程序後續的可擴展性；與此同時，在我們進行功能實現和架構設計時，或許可以更多的思考下當下的這部分功能是否可以為以後其他類似的項目和業務復用，如tcp通信時該部分代碼如何設計封裝以使之後所有其他需要用到tcp傳輸的項目可以直接移植使用或者做盡量少的改變，又如hbase,mysql,mongo等等資料庫的存取，在實現設計之初，盡量多考慮些後續代碼的復用和靈活擴展，在項目時間較為緊急的情況下，如果來不及進行比較好的封裝，那就退而求其次，通過適當的封裝內聚為以後的優化埋下伏筆，做好預備工作。

如代碼中各種靜態配置信息，常量定義，數據表名稱等等，可以將相應信息抽取到同一個配置文件或頭文件中，真正做到一處修改多處生效，提高不同環境下代碼的復用性，同時也避免各配置變更後某處引用未修改的而產生的不一致性問題。

4. 內存管理

5. 多線程/多進程/線程安全/可重入

6. 可靠性/便於運維p

後期待續ing ...

本文由威脅獵人發布，如需轉載請註明來源出處。

可關注公眾號威脅獵人（微信號：ThreatHunter）了解更多~