Tabs vs. Spaces: A Tale of Asking the Wrong Questions

Tabs vs. spaces is one of the longest-running bike sheds in software engineering. Most engineers will, if pressed, have an opinion one way or the other. Most engineering teams have an agreement of mutually assured destruction if anybody brings it up after the project has started (and, by then, the project is formatted using whatever the first two engineers wanted). The problem is not tabs vs. spaces; the problem is that this isn't something that a software engineer should care about at all. It doesn't matter.

You may think it doesn't matter because it's trivial. You're wrong! It doesn't matter because the computer can and should make this decision for you. This is what code formatters are for. We've had them for a long, long time. (For example, GNU indent, a C code formatter, has a copyright of 1989.) Your project should use them as a pre-commit hook. Let the formatter own the code format. Let yourself adapt.

Let the computer do the work.

There are some things that a formatter can't do! Naming, for example, is not only one of the hard problems in computer science, but also something that requires human thought (most of the time, anyway). Let your code reviews focus on these human concerns! That's what you, the human, are good at. You are very bad at catching all of the places where you should have a space before a {.

Let the computer do the work.

Any given engineering team can find an infinite series of excuses to not let the computer do the work; after all, when the computer does all of the work that it can do, all that's left are the difficult problems that only humans can do. It's natural to want to hold onto soothing, simple tasks that are like sorting pebbles in a stream; you're not being paid to do that.

Let the computer do the work.