Spaces considered harmful

One thing I've noticed with many projects' source, from beginner's 100-liners to sizeable high-profile
projects, is their tendency to utterly and completely fudge the indentation issue. My argument is that not
only is indentation via spaces a bad idea, it's also morally wrong. It's a silly argument.

Space indentation is a bad idea

Many projects use somewhere between 2 to 4 spaces as the "indentation unit" of their source. Speaking to
the developers, some of the reasons often given are :

"Tabs make the source too wide to read"

I've heard this numerous times, and each time I am left utterly bemused. The entire point of the hard
tab character \t is that the actual horizontal space visible from printing it is not set in stone.
You can set it to whatever you like. So in what way can tabs possibly affect the width of source ? They can't.

This doesn't even consider the fact that this complaint indicates that perhaps you need to rethink your
source anyway, if you're having real width problems. This is discussed eloquently by Linus Torvalds in
linuxbox:/usr/src/linux/Documentation/CodingStyle.

"It makes consistency impossible between developers"

Actually, if people are having trouble with using hard tabs, it means that they are having consistency
problems - logically, they must be mixing space-indented and tab-indented source. Isn't it obvious that this
is always a bad idea ? Each file and preferably each project must have a consistent style.

"I can't align comments"

Some developers like to make comments like this :

if (foo || bar) // this code is necessary
frobnicate(); // due to bug 199 in libpointless
// which hasn't been fixed yet

and complain that tabs make this sort of alignment very difficult. To which I just
say : "UGH!!". This side-commenting leads to long lines (and worse, short lines
of comments that lead to dangerous terseness on occasion) and are particularly hard
to edit. What happens when you need to add || baz == foo ? You have to play
the re-formatting game. No fun. What on earth is wrong with the time-honoured :

// this code is necessary due to bug 199 in libpointless
// which hasn't been fixed yet
if (foo || bar)
frobnicate();

Space indentation is morally wrong

I believe in the light shone by the prophets, namely using a tab size of 8. However, I accept there are other,
curious, people on this planet who prefer a different tabsize. That's OK - the wonder of hard tabbing means
they can have their cake, and I can eat it (or something like that).

Now let's consider me and the other developer (let's call him "Hagbard") working on a project together. Hagbard
started the project, using a space-based indentation unit of 2 spaces. I join in with a patch to introduce
some memory leaks and seg faults. Suddenly, I find myself forced to use spaces, and an indentation size
that is alien to me.

Let's review what has just happened. Hagbard has enforced his preferences upon me, for no good reason. It's fairly
clear from this example what's going on - Hagbard is using a fascist source management system: "you don't like
the indentation method - tough". Amazingly, space-based indentation is actually recommended in some coding
styles (for example, Python's).

The inevitable result of this, on a medium-sized project, is a horrendous mis-mash of indentation sizes and styles.
Don't stand there looking nonchalant - you've all seen such code; in universities, in business code, in student
projects. Such chaos, and all avoidable merely by using that key to the left of your keyboard !

"But tabs don't always work !"

I've heard it said that viewing diffs doesn't work properly using hard tabs. All I can suggest here is that
your tools are broken - I regularly both cat and vi patches, and they look fine. Fix your tools - don't
impose fascist policies.

Tabs do not prevent alignment. Alignment is different from indentation. For example :

We're using spaces for alignment, but tabs for indentation. Show me the editor that this
can look wrong on. The JSPWiki referenced below makes the claim that developers fuck this up.
This alone (assuming it's true) does not excuse not doing it. Developers fuck up indentation too.
The particularly bad example they show is fairly obviously from poorly-maintained software. You're
not involved in poorly-maintained software are you ?

Note that the above code isn't too great anyway. Especially with if conditions, a small
inline helper function describing the meaning of the test is often better. Don't end up like this
(from the gcc source) :

"Hey, ever heard of indent ?"

Actually, yes. indent is a program that is capable of re-formatting some sources to a standard style.
Unfortunately, it does not cover all common languages; and is not complete even in the best-supported languages
such as C. It's generally impossible to get indent to work reliably and transparently for developers
with a shared source tree.

Additionally, most editors are capable of transparently converting tabs/spaces on load and save. But of course, such things
are still unreliable, and cannot be trusted. More importantly, this isn't an argument against using hard tabs; I can
just as easily turn it around and say to space-based developers "why don't you turn this feature on ?"

Let's look at an example where automatic conversion from spaces to tabs goes wrong :

Ugh. Note that the spaces lobby, who so like their multi-line statements to align correctly,
have just forced me to read extremely badly-aligned code. More importantly, I must take considerable
care to not accidentally re-align such broken indentation, as it will not work when converted back
(here, my natural instinct to remove a tab on the line starting "cit != ..." will cause the
space-based source to look horrendous). This actually impacts on my development time, and I know
I'm not alone. Using tabs for indentation and spaces for alignment does not suffer from this problem
to anything like the same extent, since the code looks right on my screen. Using all-spaces has actually
lost data here.

The rule here is simple : tabs for indentation, spaces for alignment.

"My xterms can't copy/paste tabs"

Mine can't either, so I usually just use multiple vi sessions. However, it is possible to get this working
properly (i.e. the tabs are not converted to spaces during the paste), as I have done it previously (yes, I forget how).
Besides, there are often other things that get in the way, like line numbering. Again, broken tools do not mean it's
OK to impose your indentation methods upon me.

"I can't share files with short tabs"

Consider a user who prefers to set his tabsize to 2. He develops on a wide terminal and produces
hard-tabbed source files 80 characters wide at places (from his point of view). But you get this source,
and, using 8-sized tabs, the lines that he has written are wrapped.

On the face of it, this scenario seems like a killer argument against hard tabbing. After all, haven't
we just destroyed the possibility of sharing source nicely ?

Well, maybe, but it is not hard tabbing's fault. It is the fault of the original developer who
writes lines that are too long. This is an argument against developing using small tabsizes, not
hard tabbing per se. I would indeed recommend using a tabsize of 8, but this is not the consequence of hard
tabbing - it is the consequence of writing bad code that is too wide.

The alternative, "fixing" this problem, is to hard code 2 spaces as an indentation unit in the source. But note -
not only have we suddenly imposed indentation style on other people, but we still have the problem of
the source lines being over-filled. The problem hasn't gone away just because the indentation is fixed, instead of
variable.

"Why should I expend effort for your benefit ?"

This is the most common objection I hear - the spaces lobby ask why they should bother using tabs: they don't need it,
and they don't want it.

But this is ultimately selfish. It rings of people not writing documentation for others, because they understand
the source, and they don't need it. Obviously (before you all go hysterical) documentation is far more important
that the indentation issue, but my point is that the same attitude underlies both stances. Ultimately (assuming you
are at all interested in other people reading and modifying your source, as any good developer is) making the tiny
sacrifices you must in order to accomodate a wider range of developers will be to your benefit: if the
source is more readable to more developers, you are more likely to get patches.

Think about the relative costs and benefits. The costs are minimal; the benefits are great.