Re: On Tabs and Spaces

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