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.

first screenshot

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?

second screenshot

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:

third screenshot

And 8-character TAB setting:

fourth screenshot

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:

fifth screenshot

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

sixth screenshot

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:

seventh screenshot

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:

eighth screenshotnineth screenshot

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

tenth screenshot

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

eleventh screenshot

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.