Re: On Tabs and Spaces

On Wed, 17 Oct 2007, Christer Weinigel wrote:

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