1.少寫數字字面量
“數字字面量（integer literal）” 是指那些直接出現在代碼里的數字。它們分布在代碼里的各個角落，比如代碼 del users[0] 里的 0 就是一個數字字面量。它們簡單、實用，每個人每天都在寫。但是，當你的代碼里不斷重復出現一些特定字面量時，你的“代碼質量告警燈”就應該亮起黃燈
舉個例子，假如你剛加入一家心儀已久的新公司，同事轉交給你的項目里有這么一個函數：
def mark_trip_as_featured(trip):
"""將某個旅程添加到推薦欄目
"""
**if** trip.source== 11:
do_some_thing(trip)
elif trip.source== 12:
do_some_other_thing(trip)
**return**
這個函數做了什么事？你努力想搞懂它的意思，不過 trip.source == 11 是什么情況？那 == 12 呢？這兩行代碼很簡單，沒有用到任何魔法特性。但初次接觸代碼的你可能需要花費一整個下午，才能弄懂它們的含義。
問題就出在那幾個數字字面量上。 最初寫下這個函數的人，可能是在公司成立之初加入的那位元老程序員。而他對那幾個數字的含義非常清楚。但如果你是一位剛接觸這段代碼的新人，就完全是另外一碼事了。
使用 enum 枚舉類型改善代碼
那么，怎么改善這段代碼？最直接的方式，就是為這兩個條件分支添加注釋。不過在這里，“添加注釋”顯然不是提升代碼可讀性的最佳辦法（其實在絕大多數其他情況下都不是）。我們需要用有意義的名稱來代替這些字面量，而枚舉類型（enum）用在這里最合適不過了。
enum 是 Python 自 3.4 版本引入的內置模塊，如果你使用的是更早的版本，可以通過 pip install enum34 來安裝它。下面是使用 enum 的樣例代碼：
# -*- coding: utf-8 -*-
from **enum** import IntEnum
**class** TripSource(IntEum):
FROM_WEBSITE= 11
FROM_IOS_CLIENT= 12
def mark_trip_as_featured(trip):
**if** trip.source== TripSource.FROM_WEBSITE:
do_some_thing(trip)
elif trip.source== TripSource.FROM_IOS_CLIENT:
do_some_other_thing(trip)
... ...
**return**
將重復出現的數字字面量定義成枚舉類型，不光可以改善代碼的可讀性，代碼出現 Bug 的幾率也會降低。
試想一下，如果你在某個分支判斷時將 11 錯打成了 111 會怎么樣？我們時常會犯這種錯，而這類錯誤在早期特別難被發現。將這些數字字面量全部放入枚舉類型中可以比較好的規避這類問題。類似的，將字符串字面量改寫成枚舉也可以獲得同樣的好處。
使用枚舉類型代替字面量的好處：
· 提升代碼可讀性：所有人都不需要記憶某個神奇的數字代表什么
· 提升代碼正確性：減少打錯數字或字母產生 bug 的可能性
當然，你完全沒有必要把代碼里的所有字面量都改成枚舉類型。 代碼里出現的字面量，只要在它所處的上下文里面容易理解，就可以使用它。 比如那些經常作為數字下標出現的 0 和 -1 就完全沒有問題，因為所有人都知道它們的意思。
2. 別在裸字符串處理上走太遠
什么是“裸字符串處理”？在這篇文章里，它指只使用基本的加減乘除和循環、配合內置函數/方法來操作字符串，獲得我們需要的結果。
所有人都寫過這樣的代碼。有時候我們需要拼接一大段發給用戶的告警信息，有時我們需要構造一大段發送給數據庫的 SQL 查詢語句，就像下面這樣：
def fetch_users(conn, min_level=None, gender=None, has_membership=**False**, sort_field="created"):
"""獲取用戶列表
:param int min_level: 要求的最低用戶級別，默認為所有級別
:param int gender: 篩選用戶性別，默認為所有性別
:param int has_membership: 篩選所有會員/非會員用戶，默認非會員
:param str sort_field: 排序字段，默認為按 created "用戶創建日期"
:returns: 列表：[(User ID, User Name), ...]
"""
# 一種古老的 SQL 拼接技巧，使用 "WHERE 1=1" 來簡化字符串拼接操作
# 區分查詢 params 來避免 SQL 注入問題
statement= "SELECT id, name FROM users WHERE 1=1"
params= []
**if** min_level **is** **not** None:
statement+= " AND level >= ?"
params.append(min_level)
**if** gender **is** **not** None:
statement+= " AND gender >= ?"
params.append(gender)
**if** has_membership:
statement+= " AND has_membership == true"
**else**:
statement+= " AND has_membership == false"
statement+= " ORDER BY ?"
params.append(sort_field)
**return** list(conn.execute(statement, params))
我們之所以用這種方式拼接出需要的字符串 – 在這里是 SQL 語句 – 是因為這樣做簡單、直接，符合直覺。但是這樣做最大的問題在於：隨着函數邏輯變得更復雜，這段拼接代碼會變得容易出錯、難以擴展。事實上，上面這段 Demo 代碼也只是僅僅做到看上去沒有明顯的 bug 而已 （誰知道有沒有其他隱藏問題）。
其實，對於 SQL 語句這種結構化、有規則的字符串，用對象化的方式構建和編輯它才是更好的做法。下面這段代碼用 SQLAlchemy 模塊完成了同樣的功能：
def fetch_users_v2(conn, min_level=None, gender=None, has_membership=**False**, sort_field="created"):
"""獲取用戶列表
"""
query= select([users.c.id, users.c.name])
**if** min_level!= None:
query= query.where(users.c.level>= min_level)
**if** gender!= None:
query= query.where(users.c.gender== gender)
query= query.where(users.c.has_membership== has_membership).order_by(users.c[sort_field])
**return** list(conn.execute(query))
上面的 fetch_users_v2 函數更短也更好維護，而且根本不需要擔心 SQL 注入問題。所以，當你的代碼中出現復雜的裸字符串處理邏輯時，請試着用下面的方式替代它：
Q: 目標/源字符串是結構化的，遵循某種格式嗎？
· 是：找找是否已經有開源的對象化模塊操作它們，或是自己寫一個
o SQL：SQLAlchemy
o XML：lxml
o JSON、YAML …
· 否：嘗試使用模板引擎而不是復雜字符串處理邏輯來達到目的
o Jinja2
o Mako
o Mustache
3. 不必預計算字面量表達式
我們的代碼里偶爾會出現一些比較復雜的數字，就像下面這樣：
def f1(delta_seconds):
# 如果時間已經過去了超過 11 天，不做任何事
**if** delta_seconds> 950400:
**return**
話說在前頭，上面的代碼沒有任何毛病。
首先，我們在小本子（當然，和我一樣的聰明人會用 IPython）上算了算：11天一共包含多少秒？。然后再把結果 950400 這個神奇的數字填進我們的代碼里，最后心滿意足的在上面補上一行注釋：告訴所有人這個神奇的數字是怎么來的。
我想問的是：“為什么我們不直接把代碼寫成 if delta_seconds 呢？”
“性能”，答案一定會是“性能”。我們都知道 Python 是一門（速度欠佳的）解釋型語言，所以預先計算出 950400 正是因為我們不想讓每次對函數 f1 的調用都帶上這部分的計算開銷。不過事實是：即使我們把代碼改成****if delta_seconds ，函數也不會多出任何額外的開銷。
Python 代碼在執行時會被解釋器編譯成字節碼，而真相就藏在字節碼里。讓我們用 dis 模塊看看：
def f1(delta_seconds):
**if** delta_seconds> 12 LOAD_CONST 0 (None)
14 RETURN_VALUE
看見上面的 2 LOAD_CONST 1 (950400) 了嗎？這表示 Python 解釋器在將源碼編譯成成字節碼時，會計算 11 * 24 * 3600 這段整表達式，並用 950400 替換它。
所以，當我們的代碼中需要出現復雜計算的字面量時，請保留整個算式吧。它對性能沒有任何影響，而且會增加代碼的可讀性。
Hint：Python 解釋器除了會預計算數值字面量表達式以外，還會對字符串、列表做類似的操作。一切都是為了性能。誰讓你們老吐槽 Python 慢呢？
實用技巧
1. 布爾值其實也是“數字”
Python 里的兩個布爾值 True 和 False 在絕大多數情況下都可以直接等價於 1 和 0 兩個整數來使用，就像這樣：
>>> **True**+ 1
2
>>> 1/ **False**
Traceback (most recent call last):
File "", line 1, **in**
ZeroDivisionError: division by zero
那么記住這點有什么用呢？首先，它們可以配合 sum 函數在需要計算總數時簡化操作：
>>> l= [1, 2, 4, 5, 7]
>>> sum(i% 2== 0 **for** i **in** l)
此外，如果將某個布爾值表達式作為列表的下標使用，可以實現類似三元表達式的目的：
# 類似的三元表達式："Javascript" if 2 > 1 else "Python"
>>> ["Python", "Javascript"][2> 1]
'Javascript'
2. 改善超長字符串的可讀性
單行代碼的長度不宜太長。比如 PEP8 里就建議每行字符數不得超過 79。現實世界里，大部分人遵循的單行最大字符數在 79 到 119 之間。如果只是代碼，這樣的要求是比較容易達到的，但假設代碼里需要出現一段超長的字符串呢？
這時，除了使用斜杠 \ 和加號 + 將長字符串拆分為好幾段以外，還有一種更簡單的辦法：使用括號將長字符串包起來，然后就可以隨意折行了：
def main():
logger.info(("There is something really bad happened during the process. "
"Please contact your administrator."))
當多級縮進里出現多行字符串時
日常編碼時，還有一種比較麻煩的情況。就是需要在已經有縮進層級的代碼里，插入多行字符串字面量。因為多行字符串不能包含當前的縮進空格，所以，我們需要把代碼寫成這樣：
def main():
**if** user.is_active:
message= """Welcome, today's movie list:
- Jaw (1975)
- The Shining (1980)
- Saw (2004)"""
但是這樣寫會破壞整段代碼的縮進視覺效果，顯得非常突兀。要改善它有很多種辦法，比如我們可以把這段多行字符串作為變量提取到模塊的最外層。不過，如果在你的代碼邏輯里更適合用字面量的話，你也可以用標准庫 textwrap 來解決這個問題：
from textwrap import dedent
def main():
**if** user.is_active:
# dedent 將會縮進掉整段文字最左邊的空字符串
message= dedent("""\
Welcome, today's movie list:
- Jaw (1975)
- The Shining (1980)
- Saw (2004)""")
3. 別忘了那些 “r” 開頭的內建字符串函數
Python 的字符串有着非常多實用的內建方法，最常用的有 .strip()、.split() 等。這些內建方法里的大多數，處理起來的順序都是從左往右。但是其中也包含了部分以 r 打頭的從右至左處理的鏡像方法。在處理特定邏輯時，使用它們可以讓你事半功倍。
假設我們需要解析一些訪問日志，日志格式為：”{user_agent}” {content_length}：
>>> log_line= '"AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36" 47632'
如果使用 .split() 將日志拆分為 (user_agent, content_length)，我們需要這么寫：
>>> l= log_line.split()
>>> " ".join(l[:-1]), l[-1]
('"AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36"', '47632')
但是如果使用 .rsplit() 的話，處理邏輯就更直接了：
>>> log_line.rsplit(None, 1)
['"AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36"', '47632']
4. 使用“無窮大” float(“inf”)
如果有人問你：“Python 里什么數字最大/最小？”。你應該怎么回答？有這樣的東西存在嗎？
答案是：“有的，它們就是：float("inf") 和 float("-inf")”。它們倆分別對應着數學世界里的真負無窮大。當它們和任意數值進行比較時，滿足這樣的規律：float("-inf") 。
因為它們有着這樣的特點，我們可以在某些場景用上它們：
# A. 根據年齡升序排序，沒有提供年齡放在最后邊
>>> users= {"tom": 19, "jenny": 13, "jack": None, "andrew": 43}
>>> sorted(users.keys(), key=lambda user: users.get(user) **or** **float**('inf'))
['jenny', 'tom', 'andrew', 'jack']
# B. 作為循環初始值，簡化第一次判斷邏輯
>>> max_num= **float**('-inf')
>>> # 找到列表中最大的數字
>>> **for** i **in** [23, 71, 3, 21, 8]:
...: **if** i> max_num:
...: max_num= i
...:
>>> max_num
常見誤區
1. “value += 1” 並非線程安全
當我們編寫多線程程序時，經常需要處理復雜的共享變量和競態等問題。
“線程安全”，通常被用來形容 某個行為或者某類數據結構，可以在多線程環境下被共享使用並產生預期內的結果。一個典型的滿足“線程安全”的模塊就是 queue 隊列模塊。
而我們常做的 value += 1 操作，很容易被想當然的認為是“線程安全”的。因為它看上去就是一個原子操作 （指一個最小的操作單位，執行途中不會插入任何其他操作）。然而真相並非如此，雖然從 Python 代碼上來看，value += 1 這個操作像是原子的。但它最終被 Python 解釋器執行的時候，早就不再 “原子” 了。
我們可以用前面提到的 dis 模塊來驗證一下：
def incr(value):
value+= 1
# 使用 dis 模塊查看字節碼
import dis
dis.dis(incr)
0 LOAD_FAST 0 (value)
2 LOAD_CONST 1 (1)
4 INPLACE_ADD
6 STORE_FAST 0 (value)
8 LOAD_CONST 0 (None)
10 RETURN_VALUE
在上面輸出結果中，可以看到這個簡單的累加語句，會被編譯成包括取值和保存在內的好幾個不同步驟，而在多線程環境下，任意一個其他線程都有可能在其中某個步驟切入進來，阻礙你獲得正確的結果。
因此，請不要憑借自己的直覺來判斷某個行為是否“線程安全”，不然等程序在高並發環境下出現奇怪的 bug 時，你將為自己的直覺付出慘痛的代價。
2. 字符串拼接並不慢
我剛接觸 Python 不久時，在某個網站看到這樣一個說法： “Python 里的字符串是不可變的，所以每一次對字符串進行拼接都會生成一個新對象，導致新的內存分配，效率非常低”。 我對此深信不疑。
所以，一直以來，我盡量都在避免使用 += 的方式去拼接字符串，而是用 "".join(str_list) 之類的方式來替代。
但是，在某個偶然的機會下，我對 Python 的字符串拼接做了一次簡單的性能測試后發現： Python 的字符串拼接根本就不慢！ 在查閱了一些資料后，最終發現了真相。
Python 的字符串拼接在 2.2 以及之前的版本確實很慢，和我最早看到的說法行為一致。但是因為這個操作太常用了，所以之后的版本里專門針對它做了性能優化。大大提升了執行效率。
如今使用 += 的方式來拼接字符串，效率已經非常接近 "".join(str_list) 了。所以，該拼接時就拼接吧，不必擔心任何性能問題。