Tabs vs Spaces: Towards a Better Bike Shed
I must confess that I hadn’t been exposed to the tabs vs spaces war for a long time because, through most of my programming career, my teammates and I used to stick with the defaults so we magically avoided all the problems related to it. Luckily, none of us had strong views on the matter either. The first time I saw that it could be a problem was when I started working as a software engineer at Microsoft’s Windows Core OS Division where developers were required to use spaces over tabs on Windows source code.
Windows team itself had over 4000 engineers back in the day. It’s hard to keep everything consistent in such a scale so I perfectly understood why some rules were needed. There was no justification for spaces in the documentation but that itself is a message: consistency is much more important than what the actual choice is.
The debate about tabs vs. spaces isn’t the greatest problem in productivity space, but when people argue about it, they use arguments that are mostly irrelevant. First and the greatest is personal preference, also known as “with tabs I can see the source code the way I like”.
But you see, your tastes don’t matter. Nobody cares what you use for your personal projects that only you work on. Use emoji variable names, vertical tabs, write in Arabic, or if you want to get even crazier go ahead and use PHP, whatever takes you to the next line, to your next project. You can still see the source the way you like, even when you use spaces.
The preference of tabs vs. spaces only matters when your project is collaborative. It only matters for teams. Your personal preference means nothing in that context. So if there is one preference better than the other, it must be the one that provides easier consistency.
You should never see the source code as you like. You should see it as how the team likes. Actually, you do. Forget the tabs. What else do you see as you like on a source code when you view it? Nothing. Your IDE can’t magically transform variable naming conventions to your liking, it can’t put braces where you like without messing up the code, or it can’t apply necessary refactors so you start liking it. No. There is no such thing as viewing the source as you like in a team. You always see it as how the team sees it. And it’s a good thing too. Because the team shares the same understanding of how it should look like, code reviews are easier to do. You don’t have to stomach your peer’s preferences of viewing the source when you’re pair programming because you’ll be seeing the code as the team does.
Linus Torvalds mandated 8-character wide tabs and 80-character line length limit for Linux kernel source code, not because he is a sadist but because it makes contributors refrain from writing deeply nested code. A code that flows vertically and less-nested is much easier to read than this:
So despite using tabs, Linus forced everyone to use a fixed indent width. He ignored personal preferences because the fixed width served a significant purpose: keeping the code quality high. He might as well have mandated 8-character indents with spaces which would have made it harder to go around. Why did he pick tabs instead?
Using tabs for Linux code might have made sense from a historical standpoint. Linux source has been one of the largest open source projects consisting of millions of lines of code. Tabs could have provided faster build times and more efficient storage in the olden days of 66MHz CPUs with 4MB of memory and EIDE hard drives.
Or Linus might just have gone with the defaults, which is 8-character wide tabs for indent and retrofitted the arguments for it later. Because even if we assume a maximum of 3 indents for every line of code in today’s Linux kernel code, using tabs would amount to 100MB of savings in total. That is, you know, less than how much this browser tab occupies in your computer’s memory. So tab characters provide you no real technical advantage anymore, even in the largest projects.
EDIT 2023–08–12: I actually asked Linus Torvalds about this, and he said he had always used tabs since forever because he hated small indents, and the choice of tabs was the natural choice at the time (in the late 80’s and 90’s) when you had a wide indent like 8-characters. The reasons that made Linus Torvalds pick tabs had probably disappeared a long time ago.
You Lose Metadata with Tabs
Using tabs is lossy encoding. It destroys the information about team’s preference for the indent width. The team cannot convey their coding style preference correctly to others by example if they stick to tabs. So by using tabs, the team makes it harder for contributors to adapt, it’s a lost opportunity to educate. Spaces, on the other hand, are self-documenting in that sense.
Tab characters aren’t self-evident either. They are indistinguishable from spaces unless a tool specifically supports it. GitHub doesn’t. When you view the code for a project on GitHub, you’d have no way of knowing if the guy prefers tabs or spaces and how many characters wide just by looking at it. Your pull request for that project might contain spaces instead unless the project has a contribution guideline document and you’ve read it.
The worst thing you could do with tabs and spaces is to mix them up. Those accidents can be hard to notice too. Confusing tabs for spaces is only possible when you can actually insert the damn character into the source. Admittedly, tools can make those problems go away. But when you stick to using spaces for indents, it’s impossible to cause that problem in the first place. It isn’t possible the other way around: you can’t simply use tabs for spaces everywhere. Mix-ups are inevitable.
The “No Rule” Rule
It may not be possible to use spaces for indents all the time, like in Go language which has a strong stance to use tabs and it’s getting quite popular. It doesn’t make sense to diverge from that as the included tooling is hardwired to use tab characters. Don’t torture yourself needlessly. Stick to your team’s preference; it matters the most. Stick to established patterns. But when you have a choice, use spaces. It will make your life easier.
I haven’t even scratched the surface of the pile of arguments for both sides, and believe me, there are too many of them, but I think these are the ones that are still valid today or make sense the most.
If the new team project you’re creating is on a platform that allows a simple “Insert tabs as spaces” setting, consider using it. Think of all the hell you’d be avoiding. There are small, happy niceties of spaces.
P.S. No, you don’t have to press space multiple times to indent with spaces.
