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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
