Python PEP8 編碼規範 代碼佈局

縮減

每一級縮減使用4個空格python

續行應該與其包裹元素對其,編輯器

  1. 使用圓括號、方括號和花括號內的隱式行鏈接來垂直對其。ide

  2. 使用掛式縮進對其。當使用掛式縮進時,應該考慮到第一行不該該有參數,以及使用縮進以區分本身是續行。函數

# 與左括號對齊
foo = long_function_name(var_one, var_two,
                         var_three, var_four)

# 用更多的縮進來與其餘行區分
def long_function_name(
        var_one, var_two, var_three,
        var_four):
    print(var_one)

# 掛行縮進應該再換一行
foo = long_function_name(
    var_one, var_two,
    var_three, var_four)

不推薦:工具

# 沒有使用垂直對齊時,禁止把參數放在第一行
foo = long_function_name(var_one, var_two,
    var_three, var_four)

# 當縮進沒有與其餘行區分時,要增長縮進
def long_function_name(
    var_one, var_two, var_three,
    var_four):
    print(var_one)

  4個空格的規則對於續行是可選的。佈局

可選:性能

# 掛行縮進不必定要用4個空格
foo = long_function_name(
  var_one, var_two,
  var_three, var_four)

  

  當if語句的條件部分長到須要換行寫的時候,注意能夠在兩個字符關鍵字的鏈接處(好比if),增長一個空格,再增長一個左括號來創造一個4空格縮進的多行條件。這會與if語句內一樣使用4空格縮進的代碼產生視覺衝突。PEP沒有明確指明要如何區分if的條件代碼和內嵌代碼。可以使用的選項包括但不限於下面幾種狀況:測試

# 沒有額外的縮進
if (this_is_one_thing and
    that_is_another_thing):
    do_something()

# 增長一個註釋,在能提供語法高亮的編輯器中能夠有一些區分
if (this_is_one_thing and
    that_is_another_thing):
    # Since both conditions are true, we can frobnicate.
    do_something()

# 在條件判斷的語句添加額外的縮進
if (this_is_one_thing
        and that_is_another_thing):
    do_something()

  在多行結構中的大括號/中括號/小括號的右括號能夠與內容對齊單獨起一行做爲最後一行的第一個字符,就像這樣:this

my_list = [
    1, 2, 3,
    4, 5, 6,
    ]
result = some_function_that_takes_arguments(
    'a', 'b', 'c',
    'd', 'e', 'f',
    )

  或者也能夠與多行結構的第一行第一個字符對齊,就像這樣:編碼

my_list = [
    1, 2, 3,
    4, 5, 6,
]
result = some_function_that_takes_arguments(
    'a', 'b', 'c',
    'd', 'e', 'f',
)

製表符仍是空格?  

  空格是首選的縮進方式。

  製表符只能用於與一樣使用製表符縮進的代碼保持一致

  Python3不容許同時使用空格和製表符的縮進。 

  混合使用製表符和空格縮進的Python2代碼應該統一轉成空格。 

  當在命令行加入-t選項執行Python2時,它會發出關於非法混用製表符與空格的警告。當使用–tt時,這些警告會變成錯誤。強烈建議使用這樣的參數。

行的最大長度

  全部行限制的最大字符數爲79。

  沒有結構化限制的大塊文本(文檔字符或者註釋),每行的最大字符數限制在72。 

  限制編輯器窗口寬度可使多個文件並行打開,而且在使用代碼檢查工具(在相鄰列中顯示這兩個版本)時工做得很好。 

  大多數工具中的默認封裝破壞了代碼的可視化結構,使代碼更難以理解。避免使用編輯器中默認配置的80窗口寬度,即便工具在幫你折行時在最後一列放了一個標記符。某些基於Web的工具可能根本不提供動態折行。 

  較長的代碼行選擇Python在小括號,中括號以及大括號中的隱式續行方式。經過小括號內表達式的換行方式將長串折成多行。這種方式應該優先使用,而不是使用反斜槓續行。 

  反斜槓有時依然頗有用。好比,比較長的,多個with狀態語句,不能使用隱式續行,因此反斜槓是能夠接受的:

with open('/path/to/some/file/you/want/to/read') as file_1, \
     open('/path/to/some/file/being/written', 'w') as file_2:
    file_2.write(file_1.read())

在二元運算符以前應該換行嗎?

  幾十年來,推薦的風格是在二元運算符以後中斷。可是這回影響可讀性,緣由有二:操做符通常分佈在屏幕上不一樣的列中,並且每一個運算符被移到了操做數的上一行。下面例子這個狀況就須要額外注意,那些變量是相加的,那些變量是相減的:

# 不推薦: 操做符離操做數太遠
income = (gross_wages +
          taxable_interest +
          (dividends - qualified_dividends) -
          ira_deduction -
          student_loan_interest)

  爲了解決這種可讀性的問題,數學家和他們的出版商遵循了相反的約定。Donald Knuth在他的Computers and Typesetting系列中解釋了傳統規則:「儘管段落中的公式老是在二元運算符和關係以後中斷,顯示出來的公式老是要在二元運算符以前中斷」4。 
  遵循數學的傳統能產出更多可讀性高的代碼:

# 推薦:運算符和操做數很容易進行匹配
income = (gross_wages
          + taxable_interest
          + (dividends - qualified_dividends)
          - ira_deduction
          - student_loan_interest)

空行

  頂層函數和類的定義,先後用兩個空行隔開。 

  類裏的方法定義用一個空行隔開。 

  相關的功能組能夠用額外的空行(謹慎使用)隔開。一堆相關的單行代碼之間的空白行能夠省略(例如,一組虛擬實現 dummy implementations)。 

  在函數中使用空行來區分邏輯段(謹慎使用)。

  Python接受control-L(即^L)換頁符做爲空格;許多工具把這些字符看成頁面分隔符,因此你能夠在文件中使用它們來分隔相關段落。請注意,一些編輯器和基於Web的代碼閱讀器可能沒法識別control-L爲換頁,將在其位置顯示另外一個字形。

源文件編碼

  Python核心發佈版本中的代碼老是以UTF-8格式編碼(或者在Python2中用ASCII編碼)。 

  使用ASCII(在Python2中)或UTF-8(在Python3中)編碼的文件不該具備編碼聲明。 

  在標準庫中,非默認的編碼應該只用於測試,或者當一個註釋或者文檔字符串須要說起一個包含內ASCII字符編碼的做者名字的時候;不然,使用\x,\u,\U , 或者 \N 進行轉義來包含非ASCII字符。 

導入

  導入一般在分開的行,例如:

推薦: import os
     import sys

不推薦:  import sys, os

可是能夠這樣:

from subprocess import Popen, PIPE

  導入老是位於文件的頂部,在模塊註釋和文檔字符串以後,在模塊的全局變量與常量以前。 

導入應該按照如下順序分組:

  1. 標準庫導入

  2. 相關第三方庫導入

  3. 本地應用/庫 特定導入

  應該在每一組導入以前加入空行。

  推薦使用絕對路徑導入,若是導入系統沒有正確的配置(好比包裏的一個目錄在sys.path裏的路徑後),使用絕對路徑會更加可讀而且性能更好(至少能提供更好的錯誤信息):

import mypkg.sibling
from mypkg import sibling
from mypkg.sibling import example

然而,顯示的指定相對導入路徑是使用絕對路徑的一個可接受的替代方案,特別是在處理使用絕對路徑導入沒必要要冗長的複雜包佈局時:

from . import sibling
from .sibling import example

標準庫要避免使用複雜的包引入結構,而老是使用絕對路徑。 

不該該使用隱式相對路徑導入,而且在Python 3中刪除了它。

  當從一個包含類的模塊中導入類使,經常這麼寫:

from myclass import MyClass
from foo.bar.yourclass import YourClass

  若是上述的寫法致使名字的衝突,那麼這麼寫:

import myclass
import foo.bar.yourclass

而後使用「myclass.MyClass」和「foo.bar.yourclass.YourClass」。

  

  避免通配符的導入(from import *),由於這樣作會不知道命名空間中存在哪些名字,會使得讀取接口和許多自動化工具之間產生混淆。對於通配符的導入,有一個防護性的作法,即將內部接口從新發布爲公共API的一部分(例如,用可選加速器模塊的定義覆蓋純Python實現的接口,以及重寫那些事先不知道的定義)。 
  當以這種方式從新發布名稱時,如下關於公共和內部接口的準則仍然適用。

模塊級別的dunder名稱

  像__all__ , __author__ , __version__ 等這樣的模塊級「呆名「(也就是名字裏有兩個前綴下劃線和兩個後綴下劃線),應該放在文檔字符串的後面,以及除from __future__ 以外的import表達式前面。Python要求未來在模塊中的導入,必須出如今除文檔字符串以外的其餘代碼以前。 
好比:

"""This is the example module.

This module does stuff.
"""

from __future__ import barry_as_FLUFL

__all__ = ['a', 'b', 'c']
__version__ = '0.1'
__author__ = 'Cardinal Biggles'

import os
import sys

字符串引號

  在Python中,單引號和雙引號字符串是相同的。PEP不會爲這個給出建議。選擇一條規則並堅持使用下去。當一個字符串中包含單引號或者雙引號字符的時候,使用和最外層不一樣的符號來避免使用反斜槓,從而提升可讀性。 
對於三引號字符串,老是使用雙引號字符來與PEP 257中的文檔字符串約定保持一致。

相關文章
相關標籤/搜索