Tabs vs. Spaces: One Right Answer
Déjà Vu
Yes, I've talked about this before. I wrote that "Whitespace Is The Invisible Code Inside Your Code" and that "code is not primarily for doing things with code or computers; it's for communicating intent to the next person". Two data points is a line, three data points is a trend.
This is a trend I'm fully upfront about, though. I believe software is not necessarily about doing things faster ("Quicker is not necessarily better. Viva Code Liberte."), nor is it about getting to an arbitrary milestone faster ("despite being able to present a prototype in a short amount of time — the developer is rarely able to create a truly innovative end result.").
I think that's all of the self-referencing I'm going to do. Come with me while I explain why the Tabs vs. Spaces argument is a symptom of narcissism and should be dismissed. There is a correct choice, and those who argue against it are selfish.
Dumb Arguments
First of all, let's avoid the pitfall of arguing about keyboards. When we talk about tabs versus spaces everyone is pressing the Tab key on their keyboard. If you're a spaces person and you're mashing on the spacebar to get the right indent level you are an actual psychopath.
This argument is fundamentally about what your editor does when you press the Tab key. So let's define the terminology here:
- spaces is when you press the Tab key and the editor inserts some number of space characters (usually called a soft tab).
- tabs is when you press the Tab key and the editor inserts one tab character (usually called a hard tab).
Secondly, let's not get into talking about file sizes. *heavy sigh*. Nobody cares. If the process by which you are delivering this code is filesize-sensitive and you are not already using some kind of compression algorithm which would collapse all whitespace into a single replacement, you are doing your deployments incorrectly. Quick tip here: gzip will do this for web applications and your web server supports it and you need to turn it on.
Is there anything else? We're not talking about file size and we're not talking about what you mash your meatsicles into. We're talking about editor settings.
The Only Good Argument
The only good argument in this conversation is the exact same argument that should be made for every other code decision: what is the best choice for developer quality of life and code readability in the future?
I used to be staunchly spaces. The idea is basically: spaces look the same for every developer. The way the code is authored is the way it's displayed to every developer forever. This is a garbage argument (see how I snuck this in here instead of in the bad arguments section?). The author should not be determining how the future reader looks at the code. Do you tell other people what their editor theme should be? Do you tell them what their font size should be? If you do, you're a fascist and goodness please quit your job to save the rest of us from you.
How code looks to each developer is something that is personal to each developer, and it's not the author's business to decide that.
So, let's break down the information that we have to encode into the source:
- The line needs indentation.
- Which level of indentation.
Note here that when I say that we "have" to encode this into the source, I come to that conclusion because this is the choice that lends itself best to future code readability and developer quality of life. You may notice some kind of pattern emerging here.
Sure, you don't have to encode indentation (yes/no) and indentation (amount) into your source code.
You also don't have to encode line breaks into your source code, but I suspect that you put line breaks in there.
So you're already on the "this-is-helpful-for-readability" train. If you weren't, you'd be writing all your code on a single line. You know. Like a monster.
The Choices
Spaces encodes three things into the source:
- The line needs indentation.
- Which level of indentation.
- How to display the indentation.
It's that third item that's the problem. Whether a developer wants to display each level of indentation as 4 spaces or 2 spaces or 9 spaces or a Fibonacci sequence of spaces for each level; that's up to them. The only way to change how a bunch of spaces looks is by adjusting the font size, which has all sorts of other - practically unrelated - impacts on the reader.
Consider, instead, the tab character. This encodes only two things into the source:
- The line needs indentation.
- Which level of indentation.
It is up to the editor viewing the source - and only the editor - to determine how to display that tab. Just like it's up to the editor how to colorize the code. Just like it's up to the editor to determine what font size to display the code in.
The Illusion of Choice
So really, there isn't a choice here. If you choose spaces, you are explicitly choosing to enforce an authored display decision on future readers. If you choose tabs, you are choosing to encode only the pertinent information and let the future reader decide how to display that.
In other words, "spaces" is a result of a mindset that puts the author - at the time they write the code - at the center: What does the author think this should look like? Spaces enforces that decision to everyone else; an outpouring of narcissism that reverberates across time.
"tabs" is a result of a mindset that believes future developers can make their own decisions about how they look at code. It's a live and let live mindset that every developer should strive for: "Here's a thing that works for both of us, even though we've both made different decisions layered on top of it."
Choose tabs. Viva Code Liberte.