這篇文章主要講解了“有哪些Python編程風格”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“有哪些Python編程風格”吧！

公司主營業(yè)務：網(wǎng)站制作、成都網(wǎng)站建設、移動網(wǎng)站開發(fā)等業(yè)務。幫助企業(yè)客戶真正實現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。創(chuàng)新互聯(lián)是一支青春激揚、勤奮敬業(yè)、活力青春激揚、勤奮敬業(yè)、活力澎湃、和諧高效的團隊。公司秉承以“開放、自由、嚴謹、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領域給我們帶來的挑戰(zhàn)，讓我們激情的團隊有機會用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)推出代縣免費做網(wǎng)站回饋大家。

1.1 多余的空格

以下函數(shù)賦值符合習慣：

foo(a, b=0, {'a':1,'b':2}, (10,))

但是，下面出現(xiàn)的多余空格都不符合習慣：

# 這些空格都是多余的 foo ( a, b = 0, { 'a':1, 'b':2 }, (10, ))

下面代碼，有空格又更符合習慣：

i += 1 num = num**2 + 1 def foo(nums: List)

尤其容易忽略的一個空格，增加函數(shù)元信息時要有一個空格：

def foo(nums: list): # 此處根據(jù)官方建議nums: list間要留有一個空格 pass

1.2 是否為 None 判斷

判斷某個對象是否為None，下面符合習慣：

if arr is None: pass  if arr is not None: pass

下面寫法不符合習慣，一般很少見：

if arr == None: pass

特別的，對于list,tuple,set,dict,str等對象，使用下面方法判斷是否為None更加符合習慣：

if not arr: #為 None 時，滿足條件 pass  if arr: # 不為 None 時，滿足條件 pass

1.3 lamda 表達式

lambda 表達式適合一些key參數(shù)賦值等，一般不習慣這么寫：

f = lambda i: i&1

下面寫法更加符合習慣：

def is_odd(i): return i&1

1.4 最小化受保護代碼

要想代碼更健壯，我們一般都做防御性的工作，最小化受保護的代碼更加符合習慣，如下為了防御鍵不存在問題，加一個try:

try: val = d['c'] except KeyError: print('c' not existence)

上面寫法是合理的，但是下面代碼在捕獲KeyError時，又嵌套一個函數(shù)是不符合習慣的：

try: val = foo(d['c']) # 這樣寫也會捕獲foo函數(shù)中的KeyError異常 except KeyError: print('c' not existence)

這樣寫也會捕獲foo函數(shù)中的KeyError異常，不符合習慣。

1.5 保持邏輯完整性

根據(jù)官方指南，只有if邏輯return，而忽視可能的x為負時的else邏輯，不可取：

def foo(x): if x >= 0: return math.sqrt(x)

建議寫法：

def foo(x): if x >= 0: return math.sqrt(x) else: return None

或者這樣寫：

def foo(x): if x < 0: return None return math.sqrt(x)

所以，不要為了刻意追求代碼行數(shù)最少，而忽視使用習慣。

1.6 使用語義更加明確的方法

判斷字符串是否以ize結尾時，不建議這樣寫：

if s[-3:] == 'ize': print('ends ize')

使用字符串的endswith方法判斷是否以什么字符串結尾，顯然可讀性更好：

if s.endswith('ize'): print('ends ize')

以上這些只要平時多加注意，理解起來不是問題。其實除了PEP8指定的這些代碼編寫習慣外，還有一種與代碼健壯性息息相關的編程風格，今天重點介紹這方面的編程習慣。

2 EAFP 防御編程風格

為了提升代碼的健壯性，我們要做防御性編程，Python中的try和except就是主要用來做這個：

d = {'a': 1, 'b': [1, 2, 3]}  try: val = d['c'] except KeyError: print('key not existence')

try塊中代碼是受保護的，如果鍵不存在，except捕獲到KeyError異常，并處理這個異常信息。

而下面的代碼，一旦從字典中獲取不存在的鍵，如果沒有任何try保護，則程序直接中斷在這里，表現(xiàn)出來的現(xiàn)象就是app直接掛掉或閃退，這顯然非常不友好。

d = {'a': 1, 'b': [1, 2, 3]} val = d['c']

再舉一個try和except使用的例子，如果目錄已存在則觸發(fā)OSError異常，并通過except捕獲到然后在塊里面做一些異常處理邏輯。

import os try: os.makedirs(path) except OSError as exception: if exception.errno != errno.EEXIST: raise # PermissionError 等異常 else: # path 目錄已存在

以上這種使用try和except的防御性編程風格，在Python中有一個比較抽象的名字：EAFP

它的全稱為：

• Easier to Ask for Forgiveness than Permission.

沒必要糾結上面這句話的哲學含義。

知道在編程方面的指代意義就行：首先相信程序會正確執(zhí)行，然后如果出錯了我們再處理錯誤。

使用try和except這種防御風格，優(yōu)點明顯，try里只寫我們的業(yè)務邏輯，except里寫異常處理邏輯，幾乎無多余代碼，Python指南里也提倡使用這種風格。

但是任何事物都有兩面性，這種寫法也不例外。那么，EAFP防御風格有何問題呢?它主要會帶來一些我們不想出現(xiàn)的副作用。

舉一個例子，如下try塊里的邏輯：出現(xiàn)某種情況修改磁盤的csv文件里的某個值，這些邏輯都順利完成，但是走到下面這句代碼時程序出現(xiàn)異常，進而被except捕獲，然后做一些異常處理：

try: if condition: revise_csv # 已經(jīng)污染csv文件  do_something # 觸發(fā)異常 except Exception: handle_exception

由于try塊里的邏輯分為兩步執(zhí)行，它們不是一個原子操作，所以首先修改了csv文件，但是do_something卻出現(xiàn)異常，導致污染csv文件。

其實，除了以上EAFP防御性編程風格外，還有一種編程風格與它截然不同，它雖然能很好的解決EAFP的副作用，但是缺點更加明顯，所以Python中不太提倡大量的使用此種風格。

3 LBYL 防御編程風格

再介紹另一種編程風格：LBYL

它的特點：指在執(zhí)行正常的業(yè)務邏輯前做好各種可能出錯檢查，需要寫一個又一個的if和else邏輯。

如EAFP風格的代碼：

d = {'a': 1, 'b': [1, 2, 3]}  try: val = d['c'] except KeyError: print('key not existence')

使用LBYL來寫就是如下這樣：

if 'c' in d: val = d['c'] else: print('key not existence')

EAFP風格的代碼如下：

import os try: os.makedirs(path) except OSError as exception: if exception.errno != errno.EEXIST: raise # PermissionError 等異常 else: # path 目錄已存在

使用LBYL來寫就是如下這樣：

import os  if not os.path.isdir(path): print('不是一個合法路徑')  else: if not os.path.exists(path): os.makedirs(path) else: print('路徑已存在')

通過以上兩個例子，大家可以看出LBYL風格和EAFP風格迥異。

LBYL的代碼if和else較多，這種風格會有以下缺點。

3.1 程序每次運行都要檢查

程序每次運行都要檢查，不管程序是不是真的會觸發(fā)這些異常。

if 'c' in d: # 每次必做檢查 val = d['c']  if not os.path.isdir(path): # 每次必做檢查 print('不是一個合法路徑')  else: if not os.path.exists(path): # 每次必做檢查 os.makedirs(path) else: print('路徑已存在')

3.2 很難一次考慮所有可能異常

很難一次性考慮到所有可能的異常，更讓人頭疼的事情是，一旦遺漏某些異常情況，錯誤經(jīng)常不在出現(xiàn)的地方，而在很外層的一個調用處。這就會導致我們花很多時間調試才能找到最終出錯的地方。

def f1 if con1: # do1 if con2: # do2 # 但是遺漏了情況3，未在f1函數(shù)中報異常

3.3 代碼的可讀性下降

要寫很多與主邏輯無關的if-else，程序真正的邏輯就變得難以閱讀。最后導致我們很難看出這個只是判斷，還是程序邏輯/業(yè)務的判斷。但是，如果用try-catch，那么try代碼塊里面可以只寫程序的邏輯，在except里面處理所有的異常。

感謝各位的閱讀，以上就是“有哪些Python編程風格”的內容了，經(jīng)過本文的學習后，相信大家對有哪些Python編程風格這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關知識點的文章，歡迎關注！