Re: On Tabs and Spaces

On Wed, 17 Oct 2007, Jeff King wrote:

If you really are all one-or-the-other, then everything is obviously fine, and spaces have somewhat stronger guarantees (I say "somewhat", because the line-up-guarantee of all-spaces is only guaranteed with fixed-width fonts, and hard-tab indents often look nicer in printouts, and are generally much more flexible in just how wide you make the indent *look*, ie hard-tabs at least *allow* people to see the indents in different ways, even if that will potentially mess up any alignment).

But some mixing is inevitable, and at least in UNIX, the tendency is for tabs, not spaces, by default, so tabs have a much higher chance of *staying* mostly tabs, while anybody who uses spaces pretty much *will* get tabs inserted by just about any programming editor that isn't set up for python.

So you always get _some_ amount of mixing, exactly because most editors won't show you the difference, and what people aren't aware of, they don't think about. There's no getting away from that, unless you actually enforce it with hooks (and in a distributed environment, even that isn't really going to fly, is it?).

And if you *do* decide to enforce it with hooks, you now have issues like the fact that some files mustn't do it (autoconvert tabs to spaces in a Makefile, and it just stops working!), and others have somewhat subtle issues forcing your converter to be somewhat knowledgeable (trivial example: strings that are spread across multiple lines in C..)

In general, if you do enforce it (which I personally think is not likely a good idea, but hey, it's up to the project), I'd *still* suggest going the way of enforcing hard-tabs, not spaces. As mentioned, space does matter, but hardtabs really are "friendlier", and if you're a vi user, you can do a :set tabstop=4 and if that's what you're used to, it will all look better to you.

In contrast, all-spaces just sucks. It really has no redeeming values.

		Linus