1. 程式人生 > >Python 工匠:善用變量來改善代碼質量

Python 工匠:善用變量來改善代碼質量

是個 繼續 災難 業務 head put 函數 cit 一般來說

歡迎大家前往騰訊雲+社區,獲取更多騰訊海量技術實踐幹貨哦~

本文由鵝廠優文發表於雲+社區專欄

作者:朱雷 | 騰訊IEG高級工程師

『Python 工匠』是什麽?

我一直覺得編程某種意義上是一門『手藝』,因為優雅而高效的代碼,就如同完美的手工藝品一樣讓人賞心悅目。

在雕琢代碼的過程中,有大工程:比如應該用什麽架構、哪種設計模式。也有更多的小細節,比如何時使用異常(Exceptions)、或怎麽給變量起名。那些真正優秀的代碼,正是由無數優秀的細節造就的。

『Python 工匠』這個系列文章,是我的一次小小嘗試。它專註於分享 Python 編程中的一些偏『小』的東西。希望能夠幫到每一位編程路上的匠人。

變量和代碼質量

作為『Python 工匠』系列文章的第一篇,我想先談談 『變量(Variables)』。因為如何定義和使用變量,一直都是學習任何一門編程語言最先要掌握的技能之一。

變量用的好或不好,和代碼質量有著非常重要的聯系。在關於變量的諸多問題中,為變量起一個好名字尤其重要。

如何為變量起名

在計算機科學領域,有一句著名的格言(俏皮話):

There are only two hard things in Computer Science: cache invalidation and naming things. 在計算機科學領域只有兩件難事:緩存過期 和 給東西起名字 -- Phil Karlton

第一個『緩存過期問題』的難度不用多說,任何用過緩存的人都會懂。至於第二個『給東西起名字』這事的難度,我也是深有體會。在我的職業生涯裏,度過的作為黑暗的下午之一,就是坐在顯示器前抓耳撓腮為一個新項目起一個合適的名字。

編程時起的最多的名字,還數各種變量。給變量起一個好名字很重要,因為好的變量命名可以極大提高代碼的整體可讀性。

下面幾點,是我總結的為變量起名時,最好遵守的基本原則。

1. 變量名要有描述性,不能太寬泛

可接受的長度範圍內,變量名能把它所指向的內容描述的越精確越好。所以,盡量不要用那些過於寬泛的詞來作為你的變量名:

  • BAD: day, host, cards, temp
  • GOOD
    : day_of_week, hosts_to_reboot, expired_cards

2. 變量名最好讓人能猜出類型

所有學習 Python 的人都知道,Python 是一門動態類型語言,它(至少在 PEP 484 出現前)沒有變量類型聲明。所以當你看到一個變量時,除了通過上下文猜測,沒法輕易知道它是什麽類型。

不過,人們對於變量名和變量類型的關系,通常會有一些直覺上的約定,我把它們總結在了下面。

『什麽樣的名字會被當成 bool 類型?』

布爾類型變量的最大特點是:它只存在兩個可能的值『是』『不是』。所以,用 is、has 等非黑即白的詞修飾的變量名,會是個不錯的選擇。原則就是:讓讀到變量名的人覺得這個變量只會有『是』或『不是』兩種值

下面是幾個不錯的示例:

  • is_superuser:『是否超級用戶』,只會有兩種值:是/不是
  • has_error:『有沒有錯誤』,只會有兩種值:有/沒有
  • allow_vip:『是否允許 VIP』,只會有兩種值:允許/不允許
  • use_msgpack:『是否使用 msgpack』,只會有兩種值:使用/不使用
  • debug:『是否開啟調試模式』,被當做 bool 主要是因為約定俗成

『什麽樣的名字會被當成 int/float 類型?』

人們看到和數字相關的名字,都會默認他們是 int/float 類型,下面這些是比較常見的:

  • 釋義為數字的所有單詞,比如:port(端口號)、age(年齡)、radius(半徑) 等等
  • 使用 _id 結尾的單詞,比如:user_id、host_id
  • 使用 length/count 開頭或者結尾的單詞,比如: length_of_username、max_length、users_count

註意:不要使用普通的復數來表示一個 int 類型變量,比如 apples、trips,最好用 number_of_apples、trips_count 來替代。

其他類型

對於 str、list、tuple、dict 這些復雜類型,很難有一個統一的規則讓我們可以通過名字去猜測變量類型。比如 headers,既可能是一個頭信息列表,也可能是包含頭信息的 dict。

對於這些類型的變量名,最推薦的方式,就是編寫規範的文檔,在函數和方法的 document string 中,使用 sphinx 格式(Python 官方文檔使用的文檔工具)來標註所有變量的類型。

3. 適當使用『匈牙利命名法』

第一次知道『匈牙利命名法』,是在 Joel on Software 的一篇博文中。簡而言之,匈牙利命名法就是把變量的『類型』縮寫,放到變量名的最前面。

關鍵在於,這裏說的變量『類型』,並非指傳統意義上的 int/str/list 這種類型,而是指那些和你的代碼業務邏輯相關的類型。

比如,在你的代碼中有兩個變量:students 和 teachers,他們指向的內容都是一個包含 Person 對象的 list 。使用『匈牙利命名法』後,可以把這兩個名字改寫成這樣:

students -> pl_students teachers -> pl_teachers

其中 pl 是 person list 的首字母縮寫。當變量名被加上前綴後,如果你看到以 pl_ 打頭的變量,就能知道它所指向的值類型了。

很多情況下,使用『匈牙利命名法』是個不錯的主意,因為它可以改善你的代碼可讀性,尤其在那些變量眾多、同一類型多次出現時。註意不要濫用就好。

4. 變量名盡量短,但是絕對不要太短

在前面,我們提到要讓變量名有描述性。如果不給這條原則加上任何限制,那麽你很有可能寫出這種描述性極強的變量名:how_much_points_need_for_level2。如果代碼中充斥著這種過長的變量名,對於代碼可讀性來說是個災難。

一個好的變量名,長度應該控制在 兩到三個單詞左右。比如上面的名字,可以縮寫為 points_level2。

絕大多數情況下,都應該避免使用那些只有一兩個字母的短名字,比如數組索引三劍客 i、j、k,用有明確含義的名字,比如 persion_index 來代替它們總是會更好一些。

使用短名字的例外情況

有時,上面的原則也存在一些例外。當一些意義明確但是較長的變量名重復出現時,為了讓代碼更簡潔,使用短名字縮寫是完全可以的。但是為了降低理解成本,同一段代碼內最好不要使用太多這種短名字。

比如在 Python 中導入模塊時,就會經常用到短名字作為別名,像 Django i18n 翻譯時常用的 gettext 方法通常會被縮寫成 來使用*(from django.utils.translation import ugettext as )*

5. 其他註意事項

其他一些給變量命名的註意事項:

  • 同一段代碼內不要使用過於相似的變量名,比如同時出現 users、users1、 user3 這種序列
  • 不要使用帶否定含義的變量名,用 is_special 代替 is_not_normal

更好的使用變量

前面講了如何為變量取一個好名字,下面我們談談在日常使用變量時,應該註意的一些小細節。

1. 保持一致性

如果你在一個方法內裏面把圖片變量叫做 photo,在其他的地方就不要把它改成 image,這樣只會讓代碼的閱讀者困惑:『image 和 photo 到底是不是同一個東西?』

另外,雖然 Python 是動態類型語言,但那也不意味著你可以用同一個變量名一會表示 str 類型,過會又換成 list。同一個變量名指代的變量類型,也需要保持一致性。

2. 盡量不要用 globals()/locals()

也許你第一次發現 globals()/locals() 這對內建函數時很興奮,迫不及待的寫下下面這種極端『簡潔』的代碼:

def render(request, user_id, trip_id):
    user = User.objects.get(id=user_id)
    trip = get_object_or_404(Trip, pk=trip_id)
    is_suggested = is_suggested(user, trip)
    # 利用 locals() 節約了三行代碼,我是個天才!
    return render(request, ‘trip.html‘, locals())

千萬不要這麽做,這樣只會讓讀到這段代碼的人(包括三個月後的你自己)痛恨你,因為他需要記住這個函數內定義的所有變量(想想這個函數增長到兩百行會怎麽樣?),更別提 locals() 還會把一些不必要的變量傳遞出去。

更何況, The Zen of Python(Python 之禪) 說的清清楚楚:Explicit is better than implicit.(顯式優於隱式)。所以,還是老老實實把代碼寫成這樣吧:

    return render(request, ‘trip.html‘, {
        ‘user‘: user,
        ‘trip‘: trip,
        ‘is_suggested‘: is_suggested
    })

3. 變量定義盡量靠近使用

這個原則屬於老生常談了。很多人(包括我)在剛開始學習編程時,會有一個習慣。就是把所有的變量定義寫在一起,放在函數或方法的最前面。

def generate_trip_png(trip):
    path = []
    markers = []
    photo_markers = []
    text_markers = []
    marker_count = 0
    point_count = 0
    ... ...

這樣做只會讓你的代碼『看上去很整潔』,但是對提高代碼可讀性沒有任何幫助。

更好的做法是,讓變量定義盡量靠近使用。那樣當你閱讀代碼時,可以更好的理解代碼的邏輯,而不是費勁的去想這個變量到底是什麽、哪裏定義的?

4. 合理使用 namedtuple/dict 來讓函數返回多個值

Python 的函數可以返回多個值:

def latlon_to_address(lat, lon):
    return country, province, city

# 利用多返回值一次解包定義多個變量
country, province, city = latlon_to_address(lat, lon)

但是,這樣的用法會產生一個小問題:如果某一天, latlon_to_address 函數需要返回『城區(District)』時怎麽辦?

如果是上面這種寫法,你需要找到所有調用 latlon_to_address 的地方,補上多出來的這個變量,否則 ValueError: too many values to unpack 就會找上你:

country, province, city, district = latlon_to_address(lat, lon)
# 或者使用 _ 忽略多出來的返回值
country, province, city, _ = latlon_to_address(lat, lon)

對於這種可能變動的多返回值函數,使用 namedtuple/dict 會更方便一些。當你新增返回值時,不會對之前的函數調用產生任何破壞性的影響:

# 1. 使用 dict
def latlon_to_address(lat, lon):
    return {
        ‘country‘: country,
        ‘province‘: province,
        ‘city‘: city
    }

addr_dict = latlon_to_address(lat, lon)

# 2. 使用 namedtuple
from collections import namedtuple

Address = namedtuple("Address", [‘country‘, ‘province‘, ‘city‘])

def latlon_to_address(lat, lon):
    return Address(
        country=country,
        province=province,
        city=city
    )

addr = latlon_to_address(lat, lon)

不過這樣做也有壞處,因為代碼對變更的兼容性雖然變好了,但是你不能繼續用之前 x, y = f() 的方式一次解包定義多個變量了。取舍在於你自己。

5. 控制單個函數內的變量數量

人腦的能力是有限的,研究表明,人類的短期記憶只能同時記住不超過十個名字。所以,當你的某個函數過長(一般來說,超過一屏的的函數就會被認為有點過長了),包含了太多變量時。請及時把它拆分為多個小函數吧。

6. 及時刪掉那些沒用的變量

這條原則非常簡單,也很容易做到。但是如果沒有遵守,那它對你的代碼質量的打擊是毀滅級的。會讓閱讀你代碼的人有一種被愚弄的感覺。

def fancy_func():
    # 讀者心理:嗯,這裏定義了一個 fancy_vars
    fancy_vars = get_fancy()
    ... ...(一大堆代碼過後)

    # 讀者心理:這裏就結束了?之前的 fancy_vars 去哪了?被貓吃了嗎?
    return result

所以,請打開 IDE 的智能提示,及時清理掉那些定義了但是沒有使用的變量吧。

7. 能不定義變量就不定義

有時候,我們定義變量時的心理活動是這樣的:『嗯,這個值未來說不定會修改/二次使用』,讓我們先把它定義成變量吧!

def get_best_trip_by_user_id(user_id):
    user = get_user(user_id)
    trip = get_best_trip(user_id)
    result = {
        ‘user‘: user,
        ‘trip‘: trip
    }
    return result

其實,你所想的『未來』永遠不會來,這段代碼裏的三個臨時變量完全可以去掉,變成這樣:

def get_best_trip_by_user_id(user_id):
    return {
        ‘user‘: get_user(user_id),
        ‘trip‘: get_best_trip(user_id)
    }

沒有必要為了那些可能出現的變動,犧牲代碼當前的可讀性。如果以後有定義變量的需求,那就以後再加吧。

結語

碎碎念了一大堆,不知道有多少人能夠堅持到最後。變量作為程序語言的重要組成部分,值得我們在定義和使用它時,多花一丁點時間思考一下,那樣會讓你的代碼變得更優秀。

這是『Python 工匠』系列文章的第一篇,不知道看完文章的你,有沒有什麽想吐槽的?請留言告訴我吧。

問答
如何從變量名中獲取字符串?
相關閱讀
鵝廠優文 | ReactJS一點通
開發效率太低?您可能沒看這篇文章
用CSS畫小豬佩奇,你就是下一個社會人!
【每日課程推薦】機器學習實戰!快速入門在線廣告業務及CTR相應知識

此文已由作者授權騰訊雲+社區發布,更多原文請點擊

搜索關註公眾號「雲加社區」,第一時間獲取技術幹貨,關註後回復1024 送你一份技術課程大禮包!

海量技術實踐經驗,盡在雲加社區!

Python 工匠:善用變量來改善代碼質量