今天討論 Python 編程風格，如何寫出更加Pythonic的代碼是本篇討論的話題。

基本目錄結構：

• 1 基本編程習慣
• 1.1 多余的空格
• 1.2 是否為 None 判斷
• 1.3 lamda 表達式
• 1.4 最小化受保護代碼
• 1.5 保持邏輯完整性
• 1.6 使用語義更加明確的方法
• 2 EAFP 防御編程風格
• 3 LBYL 防御編程風格
• 3.1 程序每次運行都要檢查
• 3.2 很難一次考慮所有可能異常
• 3.3 代碼的可讀性下降

1 基本編程習慣

Python代碼的編程習慣主要參考PEP8:

https://www.python.org/dev/peps/pep-0008/

里面主要包括如每行代碼長度不超過80，函數間空一行等。同時，我們可以使用一些好用的小工具輔助我們寫出更加符合習慣的Python代碼，如flake8等小插件。

結合以上這些參考資料和工具，我們這篇專題總結就不會過多去講語法相關的格式化。而是更多精力放在一些典型的、常用的對比分析上，告訴大家常用的代碼書寫習慣，哪些寫法不夠符合習慣等。

[[334101]]

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語言，推薦使用EAFP風格，個別受保護的塊，若無法實現原子操作的地方可以使用LBYL風格。