1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
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)
|
