天天看點

Python 的縮進是不是反人類的設計?

前些天,我寫了《Python為什麼使用縮進來劃分代碼塊?》,文中詳細梳理了 Python 采用縮進文法的 8 大原因。我極其喜歡這種簡潔優雅的風格,是以對它贊美有加。

然而文章發出去後,非常意外,竟收到了大量的反對意見!!(以往文章的互動不多,此次創下了記錄)

我就不截圖了,先摘錄幾則最刺眼的評論:

最大的缺陷就是這個縮進機制

去掉花括号是最愚蠢的設計

絕對是過度設計了,缺陷很大

最大的缺點就是縮進,太反人類了

……

對于這一類的評論,我認為他們是“睜着眼睛說瞎話”,颠倒是非黑白。Python 的縮進文法如此簡潔好用,怎麼就“過度設計/愚蠢/缺陷/反人類”了?

常言道衆口難調,有人愛甜粽子有人愛鹹粽子,但是對于鹹甜味道,大家是有所共識的,不至于感官紊亂,大放厥詞。

還有比較多的評論,認為縮進容易造成混亂:

代碼多了,自己看着累,别人更難懂

眼花了,還是括号好些

還是{}或end更清晰

沒有花括号老覺得沒有安全感

縮進層次看不清楚

沒有大括号不便于閱讀

層次一多看起來很亂,不知哪層是哪層,要縮多少。到底退出循環沒有。

看着明明縮進是對的,但運作時總是報錯

用python寫上十萬行試試,到時候你就知道,什麼叫混亂看不下去

現在主流的 IDE 工具都很強大,應該善于使用其基本功能,例如:設定顯示空格字元、設定 tab 自動轉化為空格、設定 tab 鍵為 4 個空格……同一層級的縮進還會有淺淺的豎線,在視覺上輔助閱讀。

至于說層次過多、代碼很長的情況,這本身就是一種代碼壞味道!當出現過長的函數或者類時,優秀的程式員 第一時間該考慮的就是重構。推薦一本書《重構:改善既有代碼的設計》,裡面有正道的價值觀和詳盡的方法論。

還有說點選右括号,可以看到比對的左括号,會清晰。有這東西确實不錯,但沒有,我并不訴求。本身緊湊簡潔的代碼,縮進閱讀會很快。

除了以上兩大類的評論,我還收到以下幾種比較有代表性的評論:

  • 有人說“取消花括号會大大降低運作速度”、“這個特性魯棒性太低了”。——這純粹是臆想,讓他們給出論證和例子,無果。别以為在哪裡看到有人說 Python 慢,就想當然把鍋扣到縮進的頭上。
  • 有人說“多人協同編輯時,有人用tab,有人用空格”。——我說開發團隊應該統一規範,然後用 autopep8 之類的輔助工具。他說規範要不停花精力維護,要花成本。拜托!這年頭還有人不重視代碼規範,直接開除“猿籍”。
  • 有人說“縮進沒辦法自動格式化代碼”。——這在複制移動代碼,或者要改變代碼層級時,有此訴求。我一直用比較笨的方法調節(tab、shift+tab、加減空格),确實是比較笨,但是會比較有把握。剛在 PyCharm 裡研究了一下,我發現它是支援自動格式化的,隻是有個小小的問題要注意!

關于縮進的自動格式化,這裡有兩個例子,給大家示範一下:

上述例子,删除掉那行 if 條件語句,然後直接”ctrl+alt+l“作全局格式化,格式會出錯。我們希望兩句 print 向左縮進 4 格,但是 return 那句也會向左縮進。

在删除 if 那行後,如果我們隻選中兩行 print,作局部”ctrl+alt+l“格式化,那隻有這兩行會縮進,就沒問題。

再看第二個例子,我們複制了一段新代碼,但是它的縮進不對:

這時候,若直接“ctrl+alt+l”全局格式化,或者選中那三行再格式化,結果都不對!原因是第二個 if 的縮進格數小于 4 個,是以 PyCharm 認為它屬于一級縮進(即不該有空格),是以自動格式化時就把它左移了。

如果選中它們,先按 tab 鍵右移(即新代碼變成縮進大于 4 格,小于 8 格):

此時再作格式化的話,它們的縮進就跟第一層的 if 一緻了(兩層 if 是兄弟關系)。

同理,如果你想把新代碼縮進到第一層 if 的内部(變為父子關系),那隻需選中上圖三行代碼再 tab 鍵右移 4 格,之後格式化就可以了!

建議大家在編輯器裡實操一下。等空了我會錄制一期小視訊(B 站搜“Python貓”),敬請留意。

除了上面的評論/觀點之外,我們在微信交流群裡也讨論了這個話題。@櫻雨樓(https://github.com/yingyulou) 小姐姐的觀點對我挺有啟發。

群聊截圖已記錄在“Python知識星球”裡(https://t.zsxq.com/jeM33bQ),其中她提到了程式設計語言在設計上的“比較抽象和哲學”的兩點:

  • 縮進使得代碼失去了形式語言裡所謂的“上下文無關文法”,進而使得空格+數量的組合變得不再是可有可無的。
  • block 作為一個“文法組分”,需要一個定界符,而空格一般不作為文法組分,是以就覺得少了些什麼。

三言兩語沒法轉述清楚,但她談論縮進話題的視角确實令人耳目一新!

上次的文章發出後,有不少小夥伴表示很喜歡 Python 的縮進。我本以為會聽到很多這類的聲音,沒想到卻是負面的評論更多。(也許更多認同的聲音沒有表現出來)

本文對幾類典型的評論作出了回應,再次表達了我在這個話題上的關注和了解(以及情緒的抒發),希望也能給讀者們帶來一些思考和收獲吧。