I'm late in this game. But it's too classic a debate to miss the fun.

On Oct 16, 2007, at 5:45 PM, Linus Torvalds wrote:
quoted text
> 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.

Yes, all-space would look fine in patches. It'll look better than all  
tabs for tables and ascii formula and diagrams in comments, as one  
prepended character could screw up the tabs (depending on the  
content), rendering them totally unreadable. In all-space case,  
things just shift to the right by one character column.

I believe the indentation convention for ruby is 2 spaces. It looks  
tight to me :)

quoted text
> (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.

But all-space would look perfect in any editor as the authors  
intended, including the tables and ascii arts, as long as it's using  
monospace font. It's easy to setup all space editing on all platforms  
(Windows, Mac, *nix) It's also much easier to enforce. I've used pre- 
commit hook to check for tabs in the source and reject them if a tab  
is found :)

quoted text
> 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.

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

Well, we just established that all-space is perfect, look-wise.

quoted text
> 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 I mentioned, an all-space policy is trivial to enforce.

quoted text
>  - 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"?

But I still haven't seen any compelling arguments against the "all  
space" case, other than "people will screw it up into mixed spaces",  
which is really a straw man, as many multi-platform projects enforced  
the all-space policy easily by using a pre-commit hook in  
maintainers' repository.

The only downside of all-space is a moderate space bloat in source,  
which is insignificant, all things considered.

I agree that "8-character tabs are the gold standard", only for the  
tabstop==8 part but not the indent==tab part. For me the question is:  
is it really so unreasonable to just say "all-space is the holy grail"?

__Luke



-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html