The End of the Tabs vs. Spaces Debate

It’s often said that arguing with a developer is like wrestling with a pig in the mud — after a while you realize the pig likes it. In a recent team meeting, the age-old issue of tabs vs. spaces for indenting source code came up briefly for debate.

Being a total pig, I enjoy these discussions. But more importantly, it reminded me that I should write down my arguments once and for all. This article is my tabs vs. spaces manifesto. :)

(Spoiler alert: tabs are better.)

Let me first say that, as far as I’m concerned, this whole debate is scoped to programming languages where exact indentation is only a formatting aspect of which the compiler/processor is largely oblivious (the vast majority of languages). I know there are some languages out there where the exact horizontal placement of a line in relation to another carries semantic significance, but for all practical intents and purposes, for those of us working mostly with “formatting-agnostic” languages, let’s leave those esoteric aspects aside.

With that out of the way, I think perhaps the best way to express my view on this topic is by addressing in turn the two common arguments I hear from spacemen (my term-of-endearment for developers who believe spaces are a better indentation choice).

Spaceman Argument #1: “Spaces make you view the code as the author intended it”

The argument being expressed here is that, if another developer views the code file with a different tab size setting, the code will not look exactly identical on her screen as it did on mine when I wrote it.

The basic premise for this argument is silly to begin with. A code author does not (or at least should not) indend to impose her personal viewing preferences on anybody else. Encouraging or enabling her to do so is not a good thing. If you want to force other developers to view your code exactly as you wrote it, may I suggest you instead create a PDF? :)

Let me elaborate a bit on why.

There is a good reason why we use text files to store source code, and why we like to use flexible and capable editors (like the one in Visual Studio) to work with source code: we all have personal preferences in how we want source code to be displayed. Some source code viewing preferences that most of us appreciate being able to personalize include:

• Background color
• Syntax highlighting colors
• Font and font size
• Word wrapping
• Zoom

Sometimes these choices are based on habit or personal preference. Sometimes they are based on context or circumstance such as screen size, lighting conditions, etc. Sometimes they are based on disabilities such as vision impairments. And sometimes they depend on what kind of viewing I’m doing (e.g. am I comparing two files side-by-side or am I getting oriented in a huge new codebase?)

But these choices all have one thing in common: they change how the code is displayed. And that’s a good thing! As far as I know, most developers appreciate these abilities to tailor the viewing experience to their liking. I have yet to hear even spacemen argue that any of these aspects should be preserved “as the author intended the code to be viewed”.

Think about it. Would you really want the ability to enforce that another developer should use a particular font or color scheme to view your code? Surely the answer is “no!”

Indentation size really is no different: it really is purely a viewing concern and as such should be up each individual user to customize. It is every bit as much subject to the same matters of personal taste, context, circumstance and possible impairments as any other visual preference.

So why do so many developers think of indentation size differently?

Well, I think the spacemen who make this argument might fail to recognize the difference between indentation level and indentation size. Indentation level is structurally relevant, it communicates something about the code and should definitely be considered part of the code and how the author intended it, and editors should represent it with full fidelity — no objection there. But indentation size (i.e. how many pixels wide do I want one indentation level to be on my screen) is definitely not structurally relevant: that’s purily a matter of visual preference. It doesn’t matter to the structural representation of the code whether indentation levels are 2 characters wide or 4 characters wide. The visual structure remains the same, it just becomes more or less pronounced visually depending on my setting.

Spaceman Argument #2: “OK but indentation isn’t always structural, sometimes it’s used to align things!”

What spacemen mean by this argument is that they have acquired the unfortunate habit of writing code like this:

SomeNiceMethod(parameter1,
               parameter2,
               parameter3);

Here’s the thing though: using indentation this way will give you grief and extra work even if you use spaces to do it. You want to rename the method SomeNiceMethod to MyMethod? All right, go ahead. You will end up with this:

MyMethod(parameter1,
               parameter2,
               parameter3);

And now you’ll have to go and manually fix up your indentation. (Yes I know, a simple “format document” operation in many IDEs will easily fix this particular example, but general the point still stands, and you’ll end up with 3 changed lines in your commit instead of one.)

The same goes for method declarations, lambdas, or anything else where you start an artificial indentation level on an arbitrary anchor point of a previous line. On any teams or projects where I have any influence over this, I ask people to not use this type of indentation, i.e. do not base the indentation of a line on any other anchor point of a preceding line than the *start* of that preceding line, because all other anchor points are moving targets.

Instead, I encourage people to use this style:

SomeNiceMethod(
    parameter1,
    parameter2,
    parameter3);

And I want to reiterate: the reason for this principle applies regardless of whether you use tabs or spaces. And if you follow this principle, then spaceman argument #2 ceases to exist.

So there, I said it — once and for all. :) It’s out there. I’m not a spaceman, and these are my reasons.

Having said all this, I should point out that it has in fact happened that I have suggested in some teams and projects to converge on using spaces (*gasp*) because it’s what’s used in most of the existing code and/or I know most of the people working on the code prefer it.

Which brings me to my closing point: the most important thing for any code base is consistency, so whether your team or project prefer spaces or tabs for indentation is of little importance compared to the importance of making a choice and applying it consistently.