diff options
| -rw-r--r-- | content/weblog/2020-10-11_the-indentation-red-pill/index.md | 160 |
1 files changed, 160 insertions, 0 deletions
diff --git a/content/weblog/2020-10-11_the-indentation-red-pill/index.md b/content/weblog/2020-10-11_the-indentation-red-pill/index.md new file mode 100644 index 0000000..d4c2b46 --- /dev/null +++ b/content/weblog/2020-10-11_the-indentation-red-pill/index.md @@ -0,0 +1,160 @@ ++++ +title = "The indentation Red Pill" +date = 2020-10-11T13:20:52Z ++++ + +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. + +<!-- more --> + +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 typewriters[^1], + 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. + +[^1]: [Tabulating mechanism for type-writing machines.](https://patents.google.com/patent/US908221) |