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

前些天,我寫了《Python爲何使用縮進來劃分代碼塊?》,文中詳細梳理了 Python 採用縮進語法的 8 大緣由。我極其喜歡這種簡潔優雅的風格,因此對它讚美有加。python

然而文章發出去後,很是意外,竟收到了大量的反對意見!!(以往文章的互動很少,這次創下了記錄)git

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

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

去掉花括號是最愚蠢的設計安全

絕對是過分設計了,缺陷很大微信

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

……函數

對於這一類的評論,我認爲他們是「睜着眼睛說瞎話」,顛卻是非黑白。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貓」),敬請留意。

除了上面的評論/觀點以外,咱們在微信交流羣裏也討論了這個話題。@櫻雨樓(github.com/yingyulou) 小姐姐的觀點對我挺有啓發。

羣聊截圖已記錄在「Python知識星球」裏(t.zsxq.com/jeM33bQ),其中…

  • 縮進使得代碼失去了形式語言裏所謂的「上下文無關文法」,從而使得空格+數量的組合變得再也不是無關緊要的。
  • block 做爲一個「語法組分」,須要一個定界符,而空格通常不做爲語法組分,因此就以爲少了些什麼。

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

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

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

相關文章
相關標籤/搜索