為什麼程序員應該避免間接代碼?
本文討論被間接代碼毀掉的可閱讀性。
作者 | Matthew Rocklin
譯者 | 彎月,責編 | 郭芮
出品 | CSDN(ID:CSDNnews)
以下為譯文:
我常常看到有些代碼的作者為了抽象,而把細節放入某個外部函數中。請看下面的例子。
加入間接代碼之前:
# main.py
if x.startswith("foo"):
do_something_with(x)
加入間接代碼之後:
# main.py
if is_foolike(x):
do_something_with(x)
# utils.py
def is_foolike(x):
return x.startswith("foo")
這種做法的理由可能包括:
如果代碼重複多次,那麼這種抽象可以讓代碼更緊湊;
如果代碼重複多次,那麼就應該找一個位置集中管理這段邏輯,以便將來可以集中修改;
這種抽象隱藏了與功能要點無關的細節,就像散文中的腳註;
這種抽象通過函數名稱作為內聯文檔為一組操作命名;
感覺代碼更乾淨,更抽象。
學校老師就是這麼教我們的——找到一些功能,抽象出去,然後繼續。
避免間接的情況
然而,這種添加間接代碼的行為也需要付出代價。當其他人閱讀這段代碼時,他們需要在多個文件定義的多個函數之間跳轉。這種非線性的閱讀過程更加耗費閱讀者的精力。
在寫代碼的過程中,加入這種間接代碼並沒有任何問題,寫代碼的人的腦海中建立了一個抽象模型,因此將這種抽象寫入代碼是有意義的,感覺很好。但是,當其他人需要快速檢查和理解一段代碼時,就會遇到大麻煩。這發生在兩種重要的情況下:
1、在代碼審查期間。當其他人需要在代碼合併到主項目之前,檢查代碼是否合理。這些審查人員需要花費的時間大約是寫代碼的時間的十分之一。
2、將來的調試。如果代碼中存在任何問題,那麼將來完全陌生的開發人員將不得不查看這段代碼,並搞清楚代碼的內容。他們必須在幾分鐘內理解這段代碼,並確定相關的內容。他們沒有時間理解代碼背後完整的思維過程,而間接的代碼會大大減慢理解的過程。
與原來的開發過程相比,現代社區代碼中的審查和調試往往是瓶頸。因此,我經常鼓勵開發人員避免抽象,並將函數定義寫在代碼內部。
我們仍然應該使用函數
需要明確的是,我們有很多理由將複雜的邏輯分成多個函數,特別是面對重複代碼的時候,或者某些重要的政策可能會在將來發生變化時。因此,我們需要找到一個平衡點。
我希望在大多數情況下,寫代碼的人能夠意識到除了原作者之外,每個閱讀代碼的人都會感受到間接代碼帶來的附加成本。
原文:http://matthewrocklin.com/blog/work/2019/06/23/avoid-indirection
作者:Matthew Rocklin,維護與協調Python數字計算生態系統中的多個庫,特別是有關高效和可擴展的計算。
本文為 CSDN 翻譯,轉載請註明來源出處。
【END】
※程序員寫代碼為什麼需要 review?
※AI 垃圾分類指日可待?
TAG:CSDN |