寫代碼時，縮進使用 tab 還是空格？

11-26

我覺得。。。。
這都不重要，
重要的是：千萬不要混用。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

在 Elastic tabstops 面前，Space VS Tab 的聖戰可以終結了。唯一剩下的問題是，各種 IDE/編輯器什麼時候才能支持 Elastic tabstops 特性：What are the drawbacks of elastic tabstops?。

更新：這兩天寫了一個user script，給github網站加上了elastic tabstops支持。在此：https://github.com/hax/etab/blob/master/dist/github.user.js 。

通常的建議是設置你的開發工具，將一個tab設置為4個空格，輸入tab時自動轉換。（其實我不喜歡這麼干，主要是刪除時很煩，得四次退格，而我有個不良習慣就是頻繁重構代碼）

還是看你所在的環境、語言和文化。
如果團隊都是用eclipse編程，那無所謂tab和空格，統一導入一份code format，強制大家格式化代碼就行了。加上code review矯正。編程這麼多年從未因此煩惱過。
但是在其他的語言文化里，譬如ruby，習慣用兩個空格縮進，那麼你就老老實實這麼干，把IDE/Editor都設置為tab=2space，這樣就省了很多麻煩。
你用VS寫C#都遇不到這煩惱，用默認配置就的了。
你還要在linux下用VIM寫C++？Lisp？erlang？
最終建議就是你去找這個語言領域內最熱門的一個開源項目，看這幫業內最傑出的傢伙是怎麼協作的，照貓畫虎絕對不會錯。

空格，好處是任何人用任何編輯器查看代碼都是對齊的，包括網頁上查看（比如在GitHub上看代碼）。很多用tab的代碼，在網頁上查看對齊就亂了。

1）遵循團隊規範，一致性 &> 好或壞
2）必要的時候使用Tab / Sapce 轉換工具互轉
3）多寫寫Python

知乎不支持 Gif 有興趣的同學請移步縮進, Tab 還是空格? 直接拉到最下面看我錄的注釋對齊演示

我是曾經的 Tab 黨,轉為空格黨的理由只有一個,
就是 Tab 無法做到行內行末代碼或注釋的對齊,而空格啥都可以

對於輸入的問題,正經點的編輯器都支持按 Tab 輸入特定個空格,有些神器(IntelliJ IDEA)還支持根據上下文動態插入空格以達到行內/行末代碼對齊的功效,具體演示請訪問開頭提供的鏈接

HTML 里的 Tab 和空格

不管多少個連續的 Tab 還是空格,在網頁呈現的時候都會顯示成一個空格,K 數依然是個問題,不過走 Gzip 的話也不是啥問題,因為 Gzip 對重複的東西壓縮率特別高.

CSS 里的 Tab 和空格

你寫過這種整齊的 CSS 么?如果有,那麼 Tab 只能解決行首對齊,行末只能靠空格
同時,空格也能解決行首對齊

注釋里的 Tab 和空格

你寫過這種注釋么...

關於K數

我這邊的情況是LESS編譯壓縮後 Tab 和空格都沒有了,所以影響不大,HTML PHP啥的走Gzip 重複字元壓縮率也很高的,我拿zip測試如圖

操作用tab鍵，編輯器設置為使用4個空格替代

使用空格還是 tab 的這個問題，如同程序員之間的『語言之爭』，『vim/emacs編輯器之爭』一樣是個永遠的聖戰，這個爭論不會有結果，你怎麼選擇都有自己的道理，只是看你選擇認同誰而已。

就我而言，我提倡儘可能用空格（除了少數必須用tab的情形以外）。理由如下：

空格在各種情況下代碼都是你想要的樣子。而 tab 僅僅當你與代碼作者的 tab 尺寸設定為相同時，代碼才好看。
修改 tab 尺寸並不能解決這個問題，因為你很難做到每打開一個文件就修改一次 tab 尺寸，而每個人通常有不同的習慣（POSIX/Unix 標準的 tab 應當為 8 字元寬度，Linus 大神也規定 Linux 內核中所有代碼的 tab 尺寸為 8）。如果存在行章節附註釋，則 tab 尺寸更加是必須設定為與作者相同，這就意味著你看不同的代碼需要經常修改 tab 尺寸。我看過許多代碼，其使用的 tab 尺寸有從 2,3,4,5,6,8,16 甚至 32 的，如果你使用的 tab 尺寸與作者不同，外觀將很不理想。
靠譜的編輯器都能解決前進後退增加減少縮進的問題，即便是四個空格，一個退格鍵也能全退了，所以在使用的方便性方面根本不存在問題。——如果抱怨刪除調整還不能有效解決的，你需要研究一下你的編輯器了。實際上增加減少縮進在主流編輯器中都直接有快捷鍵，無論是 tab 還是空格還是退格都很少直接被用於縮進。
tab 是製表符而不是縮進符，正如在 html 頁面中大量使用&進行布局是個不好的編程習慣一樣，在編程中大量使用製表符布局通常也不是個好習慣。
如果代碼需要壓縮發布，使用空格的代碼通常具有更好的壓縮率。各位不信的可以使用批處理工具把代碼用全空格或者全 tab 走一遍。——這裡面的原理是信息量，使用 tab 縮進的代碼中，仍然不可避免的含有空格（運算符之間的間隔，注釋等等），但使用空格的代碼中根本不含有 tab，這使得 tab 縮進代碼雖然不壓縮的時候更小，但熵更高，因而壓縮率較差，壓縮之後反而更大。——當然，壓縮發布代碼僅僅對開源軟體有意義，商業軟體可以無視。

空格的好處我都知道，但是仍然我傾向於使用tab，因為這樣留下了重新解釋的餘地

就像在html/css裡面寫死font-family, font-size等style細節也是不好的設計。設計師要相信未來的瀏覽器能智能地用最漂亮的方式把信息渲染出來（safari的reader模式就是一個例子）

看看這個/w http://www.emacswiki.org/SmartTabs

看公司編碼規範就行了。

使用 Tab 來快速輸入四個空格。

在不同的編輯器里tab的長度可能不一致，所以在一個編輯器里用tab設置縮進後，在其它編輯器里看可能縮進就亂了。
空格不會出現這個問題，因為空格就佔一個字元的位置。
一般用4個空格代替tab，vim，eclipse，np++等都可以設置。

就我寫代碼經驗來看，使用tab比較好……就算要轉化成空格或者是修改tab長度，也是分分鐘的事情……我用sublime……

怎麼沒人覺得Tab寬度可調是好事呢? 這是給每個人的自由! 反而用空格的話, 有的人覺得4個空格對齊好看, 有的喜歡2個, 他們都覺得自己的寫法是最好看的, 而關鍵是以後都不可調了, 只能讓後來者順應他們, 至少我覺得不爽.

當然, 團隊中我基本上用空格, 因為空格總是不能避免 (為了對齊), 而混合使用又會被人打, 所以最終(被迫)選擇空格

順便再澄清下:
http://golang.org/src/cmd/gofmt/doc.go

6 Gofmt formats Go programs. 7 It uses tabs (width = 8) for indentation and blanks for alignment.

真的細究起來, "tab用來縮進, 空格用來對齊" 這個才是正解

這是一場聖戰,我用空格...

關鍵是
不要混用!!!
不要混用!!!
不要混用!!!

按o，然後自動的新建一行。

Tab
每行開頭加註釋不會破壞對齊

關於這個用Tab還是Space的問題可能和VI與eMacs一樣吧，我以前也是特別特別的在乎這回事兒，最開始接觸代碼的時候使用Tab，後來在網上看了各種各樣Tab的壞，改成全部使用Space，四個，後來又開始了，用兩個，再後來接觸了Python，用四個，再後來接觸了Golang，又回到Tab，這個時候才發現，這些個都是浮雲，對於自己個人來說，就使用一種自己最方便的就行了，我選擇使用Tab，因為我使用的編輯器默認就是Tab，我使用最多的Golang，不管是Space還是Tab都會在保存的時候格式化為Tab，如果說要共享，一個小小的腳本就可以了，把所有的Tab格式化為四個Space，哪裡需要什麼就格式化成什麼，如果說我要共享給別人的話，不想別人麻煩就自己格式化一下，但是有一個前提，保證整個項目都是同樣的就成。

如果是維護型的代碼，盡量用空格。因為各個操作系統和編輯器讀出來的tab未必是一樣的長度。
如果tab和空格混用情況比較多，看起來代碼很亂。
如果是新開發的代碼，編碼規範中規定用同一種類就好了。只要不混用，就沒有太多問題。