關於 Python 的縮排

by thinker

關鍵字:

由於 linkname:yungyuc http://blog.seety.org/everydaywork/ 寫了一篇 linkname:[「對 $Python$ 的新手，我建議的縮排方式」] http://blog.seety.org/everydaywork/2007/6/8/684/ 。因而，我在此發表不同看法。

關於 $Python$ 的縮排，有人說不要混合 tab 和 space ，又有人說，把 tab stop 設為 4 。當然，這些背後都有其健全、完整的理由。然而，若仔細觀察其理由，其最根本的原因，其實是 tab stop 的設定。對 $Python$ 的 interpreter 而言，不管你是用 space 或是 tab ，都有辨法處理。就算你將兩者混合做用， $Python$ Interpreter 也會聰明的，將你的 tab 字元，視為 8 個 1 ~ 8 個空白，這要視 tab 所在的位置。因此， tab 和  space 的混用並不會產生問題。

但，為什麼 PEP 8 要我們停止混用 tab 和 space 呢？我們都知道，標準的 tab stop 是 8 ，也就是 tab 會延伸到下一個 9 、 17 、 28 、 33 ．．．等位置。每個欄位以 8 個字元為其寬度， 1 ~ 8 是第一欄，而 9 ~ 16 是第二欄，以此類推。而 tab 永遠會跳到下一欄的開頭位置。然而，就是有些人們，因為某些不同的原因，而將 tab stop 設為 2 、 4 或其它數字，使的欄位的寬度和其它人不同。這就是問題的所在。當某人將 tab stop 設為 4 時，4 個 space 和一個 tab 在螢幕上產生的畫面很可能是一樣的。這會造成某些 programmer ，在將 space 和 tab 混用時，誤以為縮排是對齊的。但實際上，因為 $Python$ Interpreter 的 tab stop 為標準的 8 ，因此會發生錯誤。

所以，問題的根源並不在於混用 space 和 tab ，而是改變 tab stop 的，和標準的寬度不同所造成的。而 PEP 8 卻是呼欲我們不要混用，而不是停止修改 tab stop 。這是一種奇怪的情況，沒有將問題根源給揪出來，卻嫁禍給混用 space 和 tab 。但我相信高尚 Guido 在寫 PEP 8 時，並非有心惡搞，只是提出一個解決方案而已。然而，這個方案卻是不實際。

任何一個優秀的 programmer ，在技術養成的過程，必定也伴隨著各式僻好。這些各式各樣的僻好，只是長久以來的習慣和個人的省美觀、價值觀，總合而成，謂之為「風格」。優秀的 programmer 必定有強烈的風格，是一種可預期性，容易了解。這包括 tab 和 space 的使用習慣。因此，這種使用習慣不該被任何人撥奪，否則 programmer 則失去了一部分靈魂。

長久以來，從人們開始使用 text editor 寫程式開始， TAB 就一直是許多人的習慣。更具體而言，大部分人從一開始就被教導使用 TAB 縮排，而大部分人也確實如此。另一部分人，可能更愛用 space 做縮排，然而，這並不是問題。

問題在於，目前大部分的 text editor 都允許修改 TAB 的寬度，也就是 tab stop 。這個花僥的功能，不知是由誰開始的。然而，大部分的 project (open source) 都是使用 tab 做為縮排的標準 (不只是 $Python$)。而一個優秀的 $Python$ programmer ，大概也不只會寫 $Python$ 的程式。因此， programmer 會希望他的風格能一致，甚而參考那些風格一致的 project 。而 PEP 8 建議我們不要混用 tab 和 space 並不能解決問題，因為有些 programmer 將 tab stop 設定為 2 或 4 。這些 programmer 終究會因為使用和別人不同的 tab stop 而導至錯誤的判斷。更糟的是，還將 tab expand 成 space ，或使用 space 縮排。這將會造成縮排的錯誤而不自知。

於是有些聰明人建議完全使用 space ，使用 4 個 space 之類的。然而，你不能禁止其它人使用 tab 做為風格的一部分，畢竟這是優雅而長久的傳統。 $Python$ 沒理由具文或不具文禁止這項優良的傳統。而你也沒辨法禁止其它人，就是愛使用 tab 做為縮排，這有其歷史和正當性。因此，你也就無法避免收到以 tab 做為縮排的程式碼，畢竟這樣的 code ，比用 space 縮排的還多的多。更糟糕的是，那些將 tab stop 改為  2 、 4 ，又 expand 成 space 的人。會不小心的，將 space 和 tab 混合使用，並造成錯誤。

混合使用 space 和 tab 本身並不會造成錯誤，會造成錯誤的是修改 tab stop 並混合使用 tab 和 space 。就算你不混合使用 tab 和 space ，但因為你修改 tab stop ，也會因為別人混合使用或你使用 space 做縮排，而你又加入新的 code ，而造成錯誤。因此，修改 tab stop 實在不是一個好的主意。修改 tab stop ，並 space expand 或使用 space 縮排，就又更不明智了。

如果，你實在很想使用縮排 4 個空白，建議你直接將 tab key binding 成 4 個空白。或者，你可以設定你的 editor ， tab stop 為 4 ，並且 tab expand ，但不要 expand 讀檔進來的 tab ，也不要修改讀進來的 tab 的 tab stop (維持為 8)。如果，你的 editor 不能做到這一點，那麼最好換個 editor ，或者乖乖的打 4 個空白鍵。或你覺的標準的 tab 也還不錯，也可改用 tab 。

至於我個人，則是喜好縮排 4 個字元，但做 tab compression ，也就是自動將縮排的每 8 個空白，自動替換成一個 tab 。

為避免問題的最好做法，就是不要更改 tab stop ，至少不要改變從檔案讀進來的 tab 字元的 tab stop 。

最後更新時間: 2007-06-08 22:26:27 CST | 引用

查詢:

COMMENTS:

on 2007-06-09 14:04:12 CST

av said ..

但就像不能禁止人們使用 tab 一樣，也不能禁止人們把 tab stop 設為 4 一樣。像我們公司幾 G 的 source code 幾乎全是這樣，應該是因為 VC 預設值的關係.

on 2007-06-09 17:03:10 CST

Thinker said ..

我想, VC 的設定附合我所說的，設定 tab stop 為 4 並 tab expand ，但不對檔案裡讀到的 tab 做 expand 。我想，喜歡設定 tab stop 為 4 的人，其目的只是希望縮排四格，但卻有 tab 的定點效果，而非四個獨立的字元。然而，修改 tab stop 是一種取巧。像 VC 是能直接 handle 這種空白的縮排，但又能保留檔案裡的 tab ，才是比較正確的方式。嚴格來說， VC 所設定應該是 indent position ，而非 tab stop 。