The indentation Red Pill

Published 2020-10-11 on Yaroslav's weblog

For the last several years I had been using spaces for indentation. I had decided to settle upon that method of indentation without much thought, just based on what I observed was the most popular choice. Well, that, and also the fact that I was writing mostly Python back then, which greatly influenced my decision. Recently however, I decided to switch to using tabs - at least for my own projects - and I am going to layout here the reasons why I concluded tabs to be The Superior indentation method.

I must first mention that the thing that made me question why I used the method of indentation that I used was a neat language that I have been recently studying - Go. One of the virtues (albeit with its set of downsides) of the Go language, is that it is quite opinionated, and one of this areas is code formatting, which by definition includes indentation. And the Go way of indenting is: tabs.

Now mind you, the way they did it allows you to continue using your preferred indentation method while at the same outputting correctly formatted code as per the standard with a neat little tool called gofmt. But that is another topic for another day.

Finding out that tabs is the standard way of writing (or at least publishing) code in Go surprised me a little bit. After all, if we judge by the amount of projects in public repositories that use spaces, vs those that use tabs for indentation, then spaces is the clear winner here. I was still curious, though, as to why tabs was chosen as the standard for indentation for Go, and so I began a quest to find an answer on the Internet.

Alas, I did not find any concrete answer on the Internet from any of the people who worked on or designed the Go language. I did find myself reading a lot of arguments for and against each of the indentation methods on the Internet, which made me actually evaluate whether my choice of indentation was the better one. After all, this is one the of the oldest holy wars among programmers, that might even predate the Internet (or at least the Web).

Spaces

The main arguments for and against that I could think of, and that I gathered from other people on the Internet are as follows:

Pros

  • More consistency in how the code is presented in different text editors and environments. Mind you, after some thinking, I no longer believe this to be really a pro, and could be even considered to be a con for reasons I'll mention later in this text.
  • More people and projects use this. Not a very strong argument, considering that it is an argumentum ad populum.
  • Because of different settings on different editors, alignment with tabs might look off in some of those environments affecting readability. Now this is the strongest pro that I could think of, however, it applies more alignment, rather than indentation. More on that later.

Cons

  • Spaces - unless you or your team are masochists using one-space indentation - use more disk space than tabs. If you are using 4 spaces for indentation, arguably the most commonly used amount, then you are using at least 3 more bytes per line than if you were using tabs.
  • Spaces are meant to be used as, surprise, surprise, spaces between words. Tabs are a special character than give precisely the needed context for indentation and tabulation.
  • If you are working with other people, you are basically forcing people to an indentation setting that not only they might not prefer, but could actually hurt their productivity.

Tabs

Now I'll list the main arguments for and against using tabs. This list mostly mirrors the one on spaces, just from another point of view:

Pros

  • Freedom of choice. Using tabs means that anybody working on the same project can choose how they like the code to look on their computers, without actually changing how the code is formatted. This goes against the argument for spaces, that positions spaces as being more consistent. I believe, though, that this argument better holds for reasons I'll mention below.
  • Tabs use up less disk space than spaces do (get it, because they are called spaces, okay, maybe not), as I previously mentioned.
  • Context. Tabs were made for this purpose, all the way back to typewriters1, enough said.

Cons

  • They are not displayed consistently. Once more, this argument doesn't really hold water for reasons I'll mention later.
  • Most people and projects use spaces for indentation, which means tabs are not the preferable indentation method. Once more, argumentum ad populum.
  • Alignment might look off in different settings, but once again, alignment is not indentation, and this can be worked.

Head-to-head

It might appear at first that the arguments for and against each of the specified methods of indentation are pretty much tied. However, as I have already been mentioning, the arguments for tabs ending up being more compelling than the arguments for spaces. Let's consider the following:

  • Consistency - The pro-spaces people seem to suggest that imposing a set number of spaces as the standard for indentation achieves consistency in the code base. This, in my opinion, is very misleading, since the only consistency that you are achieving is how the code looks on the machine of everybody on the team, thus imposing the tastes of a person or group of people to everybody else, without actually improving productivity, potentially even negatively affecting productivity for some people. Take into account, that what might be readable for you (e.g., 4 spaces), might not be readable for other people, which might include visually impaired people. Ah, but some people here will be quick to point out that some editors, or code hosting solutions will just refuse to display tabs in a consistent or proper way. To which I reply, why use such incompetent software, when literally most modern text editors and IDEs have the ability to configure the amount of spaces a tab takes up on the screen?
  • Alignment - Once more, alignment is not indentation, although it does have to do with it. I do have to agree, however, that spaces are in most cases better suited for alignment, since what was aligned to look good at a tab width of, say, 4, might not look good at a tab width setting of 8. But, who said that you can't use spaces for alignment, while using tabs for indentation? Most competent text editors and IDEs should offer a setting for 'smart tabs'.
  • Most projects/people use spaces - As already mentioned, this is a fallacious argument. Just because most people do or believe something, that doesn't make it right or correct. It is worth mentioning though, that it is easier to collaborate with people when there are some standard practices in place. That said, this does not mean that you shouldn't used a better set of practices in your own projects, while also using some other standards while collaborating on others, especially taking into that most competent text editors are capable of using the indentation in use for said projects, instead of the user-set indentation. Not to mention that many languages nowadays provide tooling for formatting the code to the agreed standards.

Conclusion

After thinking about it for awhile, I came to the conclusion that tabs are indeed objectively superior to spaces mostly because of freedom, more specifically the freedom to choose the indentation spacing that is most friendly to your eyes.

Imposing a defined number of spaces on indentation, seems akin to me to mandating that people in a team use a specific color scheme for their editors, just because someone believes that "colorA on colorB is more readable than colorC on colorD, and besides, there should be consistency on the codebase".

So I decided that from this day forth, I will be using tabs in all of my personal projects, and those projects in which I have a say. Yes, even when programming in languages that suggest otherwise (I'm looking at you, Rust).

That said, I do respect the choices made by other people, and since I have a non-retarded text editor (i.e., vim) that can automatically change the indentation style based on what is already being used on a per-file basis, I can actually continue to contribute code to projects where those choices might differ from mine.

© 2018—2024 Yaroslav de la Peña Smirnov.