aboutsummaryrefslogtreecommitdiff
path: root/content
diff options
context:
space:
mode:
Diffstat (limited to 'content')
-rw-r--r--content/weblog/2020-10-11_the-indentation-red-pill/index.md160
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)