Why tabs are better than spaces

Before I present my argument for using hard tabs in code, it’s really important that I make another related argument first, so bear with me as you consider the following statement:

Aligning code is bad practice, and should be avoided. Only indentation should be used to arrange code horizontally.

The problem with aligning code

Why would I say this? First, let’s look at a common usage of alignment, along with its indented counterpart:

cancelButton.text('Cancel')
            .style({ background: 'blue' })
            .on('click', doCancel)

cancelButton.text('Cancel')
    .style({ background: 'blue' })
    .on('click', doCancel)

I think we can all agree that the aligned version looks nicer. All the chained method calls are neatly lined up and can be scanned at a glance. So why then am I arguing against it? Am I a crazed madman who hates beauty?

The catch comes in when we start working with version control, as most developers will (and should). If one were to rename the cancelButton variable in the example above to cancelLink, what changes would that involve? In the aligned example every single line of code needs to change, since cancelLink is a different number of characters to cancelButton we need to change not only the line where cancelButton occurs, but also every other line that aligns with it.

This creates bigger diffs that are more difficult to merge. Imagine that one developer performs this rename, while in a different branch, another developer renames the doCancel variable to cancelHandler. With the non-aligned version, the VCS can automatically merge these changes, since each change occurs on a different line of code. With the aligned version, this will create a merge conflict that needs to be manually resolved, costing developer time and energy, and creating the opportunity for mistakes that could cause bugs.

Much the same story exists for another common use of aligning, aligning the values of a hash:

var fruits = {
    apples:  5,
    bananas: 3,
    pears:   2,
}

var fruits = {
    apples: 5,
    bananas: 3,
    pears: 2,
}

Again, the aligned version looks nicer, but a simple change like adding a value for a new key pineapples involves a diff that touches many lines of code instead of just one.

Hence my conclusion that aligning is a bad thing, given the version control tools that are commonly used in the industry.

As an aside, I didn’t mention the extra grunt work involved in manually updating alignment when changing code. That’s because many editors can be configured to automatically realign code as needed to follow your code style. It does occur to me that our editors could potentially be modified to display our code in a neatly aligned format on the screen, but then to save it in a simpler unaligned format when written to disk, giving us the best of both worlds.

Why tabs are great

As soon as you establish that aligning code is not a good idea, the chief argument for spaces melts away:

“Tabs can be a different width in different editors, and we can’t guarantee that things line up”

Now that we’re not trying to make things line up, this becomes:

“Tabs can be a different width in different editors”

Sounds like a pretty sweet feature to me.

If you think about how controversial the tabs vs. spaces argument can get, I don’t see any reason to imagine that the number of spaces argument should be any less controversial. I’m aware of many communities that have standardized around 2 spaces, but it’s far from uncommon to see 4 spaces, or even 3 spaces being used. I don’t think there’s any good answer here, since it’s about as subjective a choice as you can find.

The correct amount to indent your code depends on your screen size, font choice, what you’re familiar with, and how your brain processes visual information. It’s deeply personal, and we’re all better off if individuals are able to customize it to their liking.

Imagine the conflict and strife that would be created if choice of editor font was embedded into every line of code, and developers had to standardize on one single font that must be used by every developer on a code base.

It would suck, and we’d all be right to demand better.

Hard tabs are the better solution. They don’t say “make this move one character over”, they simply say “indent this by one unit”, and the unit is up to you, the reader.