Tabs v/s Spaces: An analysis on why tabs are better
Tabs v/s Spaces. I am sure you have encountered this dilemma in your coding career time and again. I prefer tabs. There are some people who prefer spaces instead. Today I would like to discuss why tabs are better than spaces. I am only going to use rational points here. Please spend 5 minutes on this article and then make a decision.
First, I would like to point out the major argument why people prefer Spaces over Tabs.
They say, spaces make indentation look more consistent across different setups. This is not totally correct. Tabs can be configured to consume any number of columns in the editor. So if you hate high indentation, you can set tab width as 2. But, spaces do have a real advantage and it comes when you are trying to do non-uniform indentation like of function parameters in a function declaration.
int mainFunction(int a, char b, bool c, short d, long e,
double f, float g){
return 0;
}
int mainFunction(int a, char b, bool c, short d, long e,
double f, float g){
return 0;
}
The first function in this code uses spaces whereas the next one uses tabs. If you try to see the difference here, you will notice that double f is slightly misaligned in the second function. For me, this is not bothersome and I would gladly accept this over the benefits of tabs. Let’s look into these in detail.
1. Tabs are meant for Indentation
Why were ‘Tabs’ created when we already had spaces? For indentation right, what other could be the reason. Now tabs were introduced for indentation because indenting using space required lots of keystrokes (though it’s not the case with modern editors now). So you might still argue “I would use spaces because my editor automatically takes care of indentations for me”. Well have a look at the next points then.
2. Tab-based indentation is uniform, like spaces
As I already told at the start of this article, tab width can easily be changed in the editor to make indentation look consistent across different setups. As a bonus, tab width can be changed unlike spaces and this allows a developer who hates, say wide indentation to visualize a narrower indentation while coding.
This is the main point why people thought spaces are better. In my opinion, it’s just the opposite. Indentation using tabs is flexible in its own way.
I hope at this point of the article, I have cleared the air around tabs and why people feel that spaces are superior to tabs. At this point, we can say that spaces are pretty much equal to tabs if you don’t consider that indentation example earlier. Now let’s see, why tabs are better than spaces.
PS - It may feel like I am being picky here but hey, tabs = spaces has been established so every pro for Tabs matters.
3. Tabs work better with Notepad
You might be saying, who uses “Notepad”? Well, Notepad here symbolizes the most basic of the text editors. These editors don’t convert a tab press to 4 spaces. Now, there might be a need where you have to quickly edit a code file. If the code has been indented by spaces and you are trying to add a few lines in the code, you will have to use 4 times spaces for each level of indentation.
If the code had been indented through tabs, well .. things could have been much faster and less frustrating.
I know this happens in a very rare case but let’s face it, we all have faced these situations many times in our career.
4. Code size with tabs indentation is lesser
Suppose you are using a 4-space indentation, then the total size of the file added by your indent chars will be 4 times more than using tab indents. Now, in a complex program indents can easily go up to 5 levels. Suppose average indent in a program is 3 levels and average code length (without indents) in a line is 50 chars and total lines is 100, then the file size we have with space indentation is 100 * (50 + 3*4) = 6200. With tab indentation, total file size is 100 * (50 + 3) = 5300. This is a saving of 17%.
Yes, obviously the real numbers for the industry would be different than this. But how much less can it be, 15%, 12%, 10%? Even if we are getting a saving on 10% in the code size, don’t you think it’s beneficial. And this comes at absolutely no cost.
5. Spaces Indentation takes more time to fix
Again, this is a very rare situation but because tabs = spaces has been established after point 2, this adds weight to the tabs category.
Let’s take a situation where you accidentally deleted some spaces (n s.t. n % 4 != 0) in the indentation. To fix this, you will have to add some tab spaces for the indentation blocks (n / 4) + (n % 4) spaces for the extra. This won’t be the case with tabs as you will only have to add the tabs that were deleted.
6. Spaces promote super-ugly & inefficient code style
class MyClass:
def myDescriptiveNameMethod(param_a # description for param_a
param_b, # description for param_b
param_c): # description for param_c
pass
Yes, I have seen code examples like this in the wild. I know that you want to give comments to parameters and that’s why you are putting one parameter at a line but why this high degree of indentation. A better example using tabs would be -
class MyClass:
def myDescriptiveNameMethod(
param_a, # description for param_a
param_b, # description for param_b
param_c # description for param_c
):
pass
Yes, keeping param_a in a separate line could have been done using spaces as well but the point here is that because people use spaces for indentation, they are following a horrific code style like the first example.
So these are my pro-Tabs reasons. You might think some of them as BS but they are rational and you can’t disagree with that. The only pro-Space argument I see is the very first code example in this article. But for me, that doesn’t win against the stronger reasons we have for using tabs.
I hope this article will get programmers aware of why they should use tabs or spaces, whatever they feel like. I have tried to put together all points I have on tabs v/s spaces and I came to the decision that tabs are clearly better. This might not be the case with everyone. If this article triggered a change in your coding habit, do let me know in the comments. Also if you have a feedback about the article or would like to add to it, just throw in a comment. I am always ready to have a discussion on this topic on Twitter.
That’s all for now. Thanks for taking time reading this blabbering.
First posted on Avi's personal blog.
Sorry, forgot to mention, imho point 4 does not really apply nowadays
Besides “you can configure your editor”, I fail to see an argumentation towards tabs, sorry, Avi.
While you’ve valid arguments around “time to fix indentation” and a bit more opinionated arguments such as “super ugly & inefficient”, I find both of them shallow. They are valid points, but the time concern raised is irrelevant and super ugly, well, is just opinionated.
Albeit a space guy myself, I think much more important battle is consistency, and not a file level consistency or a project level consistency, an organizational consistency. Hell, we’re all smart guys, we can read code regardless of white-space agreements, as long as there are agreements. And then we can configure our IDE of choice, be it IntelliJ or VSCode or vi(m) or Emacs. There’s a lot more interesting battles to be held, such as adding nano to your Docker container because you lost your Vim commands A4 taped next to your computer only to see it reversed with a commit message such as “Real engineers use vi”. Now that’s something worth fighting for!
Just put a static code analysis tool in front of your pushes, and make it strict. Whether it asserts \t vs four spaces, feel free to pick. As long as it asserts.
I can have editor that does autowhitespace on screen, and process minified code in the background.