Re: On Tabs and Spaces

[Linus Torvalds <torvalds@linux-foundation.org>]

On Wed, 17 Oct 2007, Christer Weinigel wrote:
> 
> If you assume that everyone is sane and use a tab size of 8 you will
> get bitten, sooner or later.  Or actually, you, Linus, who are lucky
> enough to work mostly with Linux source, you might personally not get
> bitten all that often.  But us poor suckers that have to work with
> other people, often Windows programmers, we do.

One issue may well be that Windows programmers also probably don't work 
very much with patches, do they?

One reason for *really* wanting to use hard-tabs is that it makes patches 
look better, exactly because diffs contain that one extra (or two, in the 
case of old-style context diffs) character at the beginning of the line.

Which means that while all-space indents look fine, *mixing* styles 
definitely does not. In particular, a two-character indent (which 
hopefully nobody uses, but people are crazy) will be totally unreadable as 
a patch if you have the (fairly common, at least in UNIX projects) style 
of using spaces for less-than-eight-character-indents and tabs for the 
full 8 characters.

(In particular, a 3-level and 4-level indent will look *identical* in such 
a project, when using context diffs).

And sure, you can use all-spaces-everywhere, but that just isn't what any 
normal UNIX editors are set up for by default. In contrast, under UNIX, I 
can pretty much guarantee that hard-tab indents look at least reasonable 
in any editor.

And if you have an editor that shows hard-tabs as 4-character indents, 
generally you can work with it. You may have odd indentation, and people 
may complain about your patches not lining up, and yes, it would be up to 
*you* to understand that 8-wide tabs are the normal and default. But you 
can certainly work with a source base that uses a single hard-tab for 
indentation.

In contrast, if you use spaces (or worse - mixing), things really look 
ugly as sin, to the point of actually being unworkable.

In short:

 - if the project has the rule that an indentation is "one hard-tab", then 
   at least everybody can *work* with that project. Different people may 
   see things laid out slightly differently, but it's generally not a 
   horrible disaster, especially if you aim to use block comments indented 
   with the code (like we *mostly* do both in the kernel and in git)

 - all-space and all-tabs just leads to problems. Yes, I know about 
   python, but lets face it, python is different, since the spacing has 
   semantic rules there. Most non-python programmers will not use editors 
   where you can obviously see the difference between spaces and tabs, and 
   as a result an all-space model will *turn* into a mixed-space/tab 
   model, and you get horrible end results.

 - as per above, mixing spaces and tabs is a *horrid* idea. 

 - as a result, a "pure tab for indents" model tends to be workable in 
   most situations. It may not be ideal for you, but it's workable.

 - and at least in the UNIX world, default for pure tabs really is 8 
   characters. Even if you have an editor that shows them as four, you'll 
   see different results outside the editor (eg "grep -5 file.c"), so 
   people should just consider other tab sizes to be "secondary".

   And as long as 99% of all git developers are under Linux, and all the 
   core ones seem to have had no problem with the current tab rules, I 
   really don't see why that should change.

See? Hard-tabs are good. Maybe Windows people don't ever see patches 
(perhaps they only see them as side-by-side graphical things), and maybe 
windows projects are always done inside *one* environment where there is 
no "grep" and "terminal TAB size" and "fifty different editors with 
different defaults".

But even in DOS/Windows, hard-tabs seem to be quite common, judging by 
what little source code I've seen from Windows projects. 

And I just checked. The current git model seems to work fine if you have 
an editor that thinks tabs are 4 spaces:

	sed 's/	/    /g' < revision.c  | less -S

(that's a hard-tab in that first regex). No, things don't necessarily line 
up just like they should, but you actually have to *look* for problems to 
see them (ie stuff where people have added line-breaks).

And is it really so unreasonable to just say "8-character tabs are the 
gold standard"?

			Linus