Yeah, that's right. You heard me. Tabs are better than spaces. Those of you who know what I'm talking about probably just threw your keyboard across the room in a pedantic rage. "Heresy!" I hear you call from across the digital void. Get the torches! Burn him at the stake! Demon! Witch!
The rest of you are probably asking yourselves what the hell I'm talking about. So, I'll make the explanation as short as I can. When writing code and programming, related blocks of code are generally indented for readability, much like you would indent sub-items in an outline. This is generally not necessary (except for certain languages like python), but if you ever want to be able to read and edit your code later, is pretty much required. Some people like to indent with tab characters, while others prefer to use multiple spaces (usually 2 or 4) to indent code blocks. And people rage about this for some reason.
Look, I get it, you're writing code on a project, or for a company that has code standards and they require spaces instead of tabs. The first time you encounter this requirement (if you're a tab indenter), you probably asked why. Whoever was in charge of the code standards gave you some bullshit answer and you drank the kool-aid. Now you pass that shit on as gospel without really thinking about it.
Tabs are Superior, and I'll Tell You Why
Yes, it's my opinion, but after I explain my reasoning, you'll either agree or not. And if not, you'll probably first look for a place where you can try and debate me, then, finding no commenting or contact form, you'll probably find some other forum to hold a one-sided debate. Have fun.
1. Portability
Yes, this is probably why you were told to use spaces in the first place. Let me see if I've got the gist of it... "Tabs are huge (8 spaces) and make code unreadable in many instances, and may be different sizes in different editors. To make sure everyone is looking at the same code use 4 spaces instead."
That has got to be the most backward thinking, and it stems from an issue that no longer exists. Yes, this was absolutely an issue decades ago when we were programming in shell windows and command-line editors which wrapped at 80 characters. When you only have 80 characters per line to work with, losing 8 characters per indentation is a lot.
Guess what, this isn't an issue anymore. First of all, there is virtually no instance anymore where an editor is limited to 80 character lines. Most of us develop on widescreen monitors, in huge IDEs, or even in command-line editors with far more than 80 characters. Tabs are not expensive in terms of character space anymore.
This brings me to my second point. Almost every code editor I have used in the past decade lets users specify how many whitespace characters a tab represents. Whether it's an IDE, Text Editor, VI, or Emacs. With every editor I've used I can say, "set tabs to 2 spaces," or "set tabs to 4 spaces" (my preferred setting).
Forcing all of your developers to use a set number of spaces, so everyone sees the indentation the same is ableist and ridiculous. What if my eyes don't easily let me discern code indentation at your required 2 spaces? What if I need the standard 8 spaces in order to read the code? The only option your ridiculous code standards leave me is to reindent every file I work with and then again when I save and commit, or to just suffer through it, probably reducing productivity a lot.
Portability is being able to use one type of indentation in a file (tabs), and then letting the developer decide how that should look for their needs, without changing the actual code or having to walk in a shoe that doesn't fit.
2. Code Size
This one's pretty easy, each character in source code takes 1 byte of storage (for the most part). Each tab character is 1 byte. Each space is 1 byte. That means if you indent with two spaces, your indentation takes double the storage space as tabs. If you indent with four spaces, it takes four times the space.
Let's look at some real numbers. My "real job" website has just under 420,000 lines of code (for front- and back-end). Within those files are 2,883,834 indentations (counting each level of indentation for each line). I know this because I can run a few Linux commands to count the tab characters in all files in the repository.
Here's the command:
git ls-files | find . -type f -exec cat {} + | tr -cd '\t' | wc -mThis command lists all the files in the repository, concats them together, removes every character that's not a tab, and then counts the remaining tabs. Note that this command won't work if you indent with spaces.
That means that indentation alone in my source files accounts for 2,883,834 bytes of storage, or about 2.75 MB. If I used two spaces for indentation, that would double to 5.5 MB, and if I used four spaces, would double again to 11 MB. While that's not much with today's HD space, it can affect everything from storage to memory usage, transfer speeds, and performance.
3. Keystrokes
You may have an editor that automatically indents code as you write it, and that's great, but if you have to change the indentation, tabs are better than spaces. Some editors can tell when you're trying to unindent something and do it for you, but they frequently get it wrong. This means if you want to unindent several lines of code, you may have to hit DEL or BKSP four times for each line versus the one time for tab characters.
"Big deal," I hear you say, "so you have to hit a key a few extra times." Obviously, you've never had to fix someone else's fucked up indentation across thousands of lines of code. I have. And when spaces are involved, it's a nightmare.
4. Spaces Promote Mistakes
Say you need to re-indent a source file. Maybe your IDE can do it, but maybe you use a "search and replace". Well, I hope you know for sure that your actual content in your source files doesn't include double or quadruple spaces, or else a writer/editor may come to hunt you down when the content is changed. Generally, we don't include actual tabs in our content (especially web content, since they're ignored).
It's also really easy to accidentally miss a space or add an extra one without noticing it. A single space doesn't move a line of code so much that it is immediately obvious, unlike missing a tab character.
That's It, That's My Rant
For all of these reasons, tabs are better than spaces, yet the majority of development projects and companies still want to enforce spaces for indentation. Mostly for the sole reason that every developer sees the source code exactly the same, whether they want to or not.
It's time to stop. Yes, this is a rant, and yes, I'm just as rage-filled about this as the other side of the fence. Mostly due to the inordinate amount of time I waste fixing other people's indentation, which is almost always screwed up because they chose spaces. And it takes far longer because they chose spaces.
If you ever work on one of my projects, I'm sorry to say you'll be required to use tabs. Fortunately, I'll help you set up your editor to see them however you want. You know, for portability. Same code, but displayed per the preference of the developer.
Not that anyone will read this.
