You're using TABs in a wrong way

Sun, 11 February 2018 :: #spaces :: #tabs :: #rant

Tabs or spaces? I'm sure you have a strong opinion on this subject, as probably everyone. Can we summarize the arguments for each side?

Advantages of TABs:

  1. Using TABs means the source code uses less space. Each 4 bytes (2 bytes if you're a Ruby programmer, or sometimes 8 bytes) is compressed to 1 byte, so we're efficient.

  2. Inserting TAB is faster than inserting few spaces. People often would feel stupid when they'd try to hit 4 spaces to add an indentation to a new code block. Also, navigation across the file is faster with TABs. Why hit left left left left when you can just use one left key to go backwards an indentation level?

  3. It's more flexible. You can use 2-character indentation if you want. You can later switch to 4-character indentation if you'd like. If you give your code to a co-worker that uses 8-character indentations per block, this won't be a problem, because TABs can abstract the presentation layer of the source code; you can use an editor option to modify the view.

  4. TAB is a character that is made for indentation. It has no other purpose. So why use something else instead?

  5. It's impossible to make a mistake in indentation, I mean it's impossible to half-indent a line. You either indent or don't, the outcome is binary.

So, what do we have for SPACEs? I think I see just one advantage of using SPACE:

  1. The code looks the same, no matter the application or device you're using.

So why are people still using SPACEs when it's clear that TABs are simply superior? Let's see how TABs behave on a few examples.


In the example above we have a comment that is aligned with TABs. Current setting is 4-characters per TAB. What happens when we'll switch this setting to 8-characters per TAB?


So I guess that arguments number 3 and 5 go out of the window. Can we debug it and see what is happening? Let's look at this again with more details; again, 4-character TAB setting:


And 8-character TAB setting:


So we see here that with 8-character TAB setting we have a superfluous TAB character in the second comment. So using TABs doesn't give you any separation of the presentation layer from the structure layer, because now we have to change our structure in order to have a desired look.

Another example. 4-character TAB setting:


8-character TAB setting, clearly the indentation is broken:


How to fix this?

Actually you can't solve this by using TABs alone. You have to reinforce them with spaces. Use TABs only until the first non-whitespace character in the line. For the rest of your indentation needs, use spaces. Like this:


This way the 8-character TAB setting (like in the image above) works correctly, the 4-character TAB setting works correctly and 2-character TAB setting works correctly as well:



So remember, next time you're going to wonder why you shouldn't use TABs in situations like this:


is because after changing TAB setting you might end up with this:


Using spaces liberates you from such problems. Also you don't need to hit space 4 times in order to do indentation, because you can still use the TAB key. You also don't need to move through the file by using cursors alone, you can use ctrl+cursor key to skip whole words and all whitespaces at once.

The downside is that everyone will need to use your indentation level. Don't like 2-character indentation? Tough luck, try another codebase.

So the ultimate solution? Use TABs and spaces ;). This way you'll get the best of both worlds: flexibility and freedom on whatever TAB setting you'd like to use, and persistent look across all applications and devices.