英文原文:
https://www.python.org/dev/peps/pep-0008/
PEP: | 8 |
---|---|
Title: | Style Guide for Python Code |
Author: | Guido van Rossum, Barry Warsaw, Nick Coghlan |
Status: | Active |
Type: | Process |
Created: | 05-Jul-2001 |
Post-History: | 05-Jul-2001, 01-Aug-2013 |
自己嘗試翻譯成中文,速度緩慢…
介紹(Introduction)
本文檔給出了Python主要發行版中標準庫代碼所遵守的編碼規範。Python的C語言實現中的編碼規範,請參考PEP編碼風格指南。
本文檔和PEP 257(Docstring約定)都是改編自Guido最初的Python風格指南文章,並補充了一些Barry的風格指南。
由於開發語言在不斷的進化,所以本文當也會隨着時間的變化添加新的約定或者修改過時的約定。
很多項目會有自己的風格指南。如果有一些和本指南衝突的地方,使用項目特定的指南優先於本指南。
墨守成規的做法是愚蠢的(A Foolish Consistency is the Hobgoblin of Little Minds)
Guido的主要觀點之一就是:一段代碼讀的次數總是比編寫的要多。本指南旨在提高代碼的可讀性,並且在各種Python代碼中保持一致。和PEP 20所說的“可讀性至關重要”有異曲同工之妙。
本指南是關於一致性的。 保持本指南的一致性很重要,保持項目的一致性更爲重要, 保持一個模塊或功能內的一致性則是最重要的。
然而,要知道什麼時候可以不一致 —— 有的時候本指南是不適用的。當你有疑問的時候,請給出自己的最佳判斷,查看其他例子確定最合適的方法。不要猶豫的去提出問題!
特別提示的是:不要僅僅爲了遵守本PEP指南而破壞向後兼容性!
如果有以下原因,可以忽略本指南:
- 當應用指南時代碼的可讀性降低,即使對於那些習慣閱讀遵循此PEP的代碼的人來說也很難讀的時候。
- 需要與其他代碼保持一致,但是這些代碼不符合本指南的時候(可能是出於歷史原因)。雖然這也是收拾別人爛攤子的好機會(在真正的XP風格中)。
- 這段代碼在引入指南之前編寫的時候,可以不修改。
- 當代碼需要與不支持風格指南建議功能的舊版Python保持兼容時。
代碼佈局(Code Lay-out)
縮進(Indentation)
每個縮進級別使用4個空格。
連續行所包裝的元素應該要麼採用Python隱式續行,即垂直對齊於圓括號、方括號和花括號,要麼採用懸掛縮進(hanging indent)。採用懸掛縮進時需考慮以下兩點:第一行不應該包括參數,並且在續行中需要再縮進一級以便清楚表示。
正確的例子:
# Aligned with opening delimiter.
foo = long_function_name(var_one, var_two,
var_three, var_four)
# Add 4 spaces (an extra level of indentation) to distinguish arguments from the rest.
def long_function_name(
var_one, var_two, var_three,
var_four):
print(var_one)
# Hanging indents should add a level.
foo = long_function_name(
var_one, var_two,
var_three, var_four)
錯誤的例子:
# Arguments on first line forbidden when not using vertical alignment.
foo = long_function_name(var_one, var_two,
var_three, var_four)
# Further indentation required as indentation is not distinguishable.
def long_function_name(
var_one, var_two, var_three,
var_four):
print(var_one)
對於連續行,4空格規則不是必須遵守的。
可選的例子:
# Hanging indents *may* be indented to other than 4 spaces.
foo = long_function_name(
var_one, var_two,
var_three, var_four)