您好,登錄后才能下訂單哦!
這篇文章主要講解了“有哪些Python編程風格”,文中的講解內容簡單清晰,易于學習與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學習“有哪些Python編程風格”吧!
1.1 多余的空格
以下函數賦值符合習慣:
foo(a, b=0, {'a':1,'b':2}, (10,))
但是,下面出現的多余空格都不符合習慣:
# 這些空格都是多余的 foo ( a, b = 0, { 'a':1, 'b':2 }, (10, ))
下面代碼,有空格又更符合習慣:
i += 1 num = num**2 + 1 def foo(nums: List)
尤其容易忽略的一個空格,增加函數元信息時要有一個空格:
def foo(nums: list): # 此處根據官方建議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參數賦值等,一般不習慣這么寫:
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時,又嵌套一個函數是不符合習慣的:
try: val = foo(d['c']) # 這樣寫也會捕獲foo函數中的KeyError異常 except KeyError: print('c' not existence)
這樣寫也會捕獲foo函數中的KeyError異常,不符合習慣。
1.5 保持邏輯完整性
根據官方指南,只有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)
所以,不要為了刻意追求代碼行數最少,而忽視使用習慣。
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保護,則程序直接中斷在這里,表現出來的現象就是app直接掛掉或閃退,這顯然非常不友好。
d = {'a': 1, 'b': [1, 2, 3]} val = d['c']
再舉一個try和except使用的例子,如果目錄已存在則觸發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.
沒必要糾結上面這句話的哲學含義。
知道在編程方面的指代意義就行:首先相信程序會正確執行,然后如果出錯了我們再處理錯誤。
使用try和except這種防御風格,優點明顯,try里只寫我們的業務邏輯,except里寫異常處理邏輯,幾乎無多余代碼,Python指南里也提倡使用這種風格。
但是任何事物都有兩面性,這種寫法也不例外。那么,EAFP防御風格有何問題呢?它主要會帶來一些我們不想出現的副作用。
舉一個例子,如下try塊里的邏輯:出現某種情況修改磁盤的csv文件里的某個值,這些邏輯都順利完成,但是走到下面這句代碼時程序出現異常,進而被except捕獲,然后做一些異常處理:
try: if condition: revise_csv # 已經污染csv文件 do_something # 觸發異常 except Exception: handle_exception
由于try塊里的邏輯分為兩步執行,它們不是一個原子操作,所以首先修改了csv文件,但是do_something卻出現異常,導致污染csv文件。
其實,除了以上EAFP防御性編程風格外,還有一種編程風格與它截然不同,它雖然能很好的解決EAFP的副作用,但是缺點更加明顯,所以Python中不太提倡大量的使用此種風格。
3 LBYL 防御編程風格
再介紹另一種編程風格:LBYL
它的特點:指在執行正常的業務邏輯前做好各種可能出錯檢查,需要寫一個又一個的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 程序每次運行都要檢查
程序每次運行都要檢查,不管程序是不是真的會觸發這些異常。
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 很難一次考慮所有可能異常
很難一次性考慮到所有可能的異常,更讓人頭疼的事情是,一旦遺漏某些異常情況,錯誤經常不在出現的地方,而在很外層的一個調用處。這就會導致我們花很多時間調試才能找到最終出錯的地方。
def f1 if con1: # do1 if con2: # do2 # 但是遺漏了情況3,未在f1函數中報異常
3.3 代碼的可讀性下降
要寫很多與主邏輯無關的if-else,程序真正的邏輯就變得難以閱讀。最后導致我們很難看出這個只是判斷,還是程序邏輯/業務的判斷。但是,如果用try-catch,那么try代碼塊里面可以只寫程序的邏輯,在except里面處理所有的異常。
感謝各位的閱讀,以上就是“有哪些Python編程風格”的內容了,經過本文的學習后,相信大家對有哪些Python編程風格這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是億速云,小編將為大家推送更多相關知識點的文章,歡迎關注!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。