Tabs or spaces?
Every programmer was at some point confronted by this career-defining choice. But with this post today I'll expand the horizon and finally settle the debate.
So let's go over the different ways to indent your code and their pros and cons.
All of the pretty code images here were made using carbon.
Indenting as ASCII intended.
The pros of this technique are plenty:
- Every reader of the code can decide how much space it wants the IDE to attribute to one tab: 1, 5 or even 7 (sadly fractions are not supported by most).
- The resulting file size is smaller, ensuring that you can stay as productive as possible.
- You feel good giving purpose to the 10th ASCII character.
Ah, the default for most editors.
And also slightly more common than tabs in my objective experience.
The main advantage of this style is that you can force the reader of your code to use the same length of indentation that you used.
I know I listed the opposite point as an advantage of using tabs, but we all know that in the end you cannot trust users – not even the users of an IDE.
Developers new to the discussion often bring up that this style requires you to press the space bar repeatedly.
But of course noone actually does that – that's what auto-clickers are for.
Okay, hear me out: You can use tabs and spaces for different kinds of indentation.
For instance you could use tabs to indent blocks and then use spaces when you need something at a specific position, like when aligning the second parameter with the first.
This allows other people to still choose their own length for the tabs, but ensure that elements are still aligned when you want them to be.
Personally I also advocate to use tabs instead of spaces in between parameters, because that will create more visually pleasing code.
For those that hate to be restricted by style guides and want to rebel against the bourgeoisie of coding, you can just do whatever you want and sometimes use tabs and sometimes use spaces.
This might seem weird, but if you look at the first projects of software engineers, you'll find that this is pretty common before they learn otherwise.
So it might just be the most natural of all of the indenting methods.
Plus, it turns programming into a small game, when, in every line, you'll wonder whether spaces or tabs were used.
And gamification improves cognitive, motivational and behavioral learning, so this method will also make you a better programmer in the long run.
Lastly, you can actually fit two programs into one: Since the whitespace is ignored by most programing languages, you can use them to implement a separate program.
That makes for a great easter egg!
Instead of adding another program, you could also just try to use the space more efficiently.
Since you'll likely decide to indent anyways, why let that space go to waste?
You can use block comments to add more useful information about what's happening in each line.
That's especially useful for beginners so you don't forget to comment your code.
Since you don't want to use up too much space with full text comments all the time, I'd recommend using some well-defined short names.
Here are some suggestions by me:
|Short Name||What it describes|
||End of a block|
This also increases searchability of your code since you can just search for "⏎" and find all of the returns in the file.
More and more language now move to a cleaner no-semicolons-required style.
Sadly some languages still haven't caught up.
But when you're using semicolons as indentation, you'll never have to worry about seeing one at the end of your statement ever again.
Sadly some languages set (in my opinion) unreasonable restrictions on code when using this indentation style.
Java for instance will only allow you to use one indentation level for the line after a
Otherwise it will complain about "unreachable code".
In those cases I'd recommend using a pre-compiler job that runs all of the files through a simple
sed -r "s/;+/;/g" call, which will fix some of the errors.
Most languages also won't let you chain calls over multiple lines anymore.
I do see this as an absolute win, however, since I believe that no method should consist of more than one statement, anyways.
That's usually a code smell.
Other languages will outright refuse to compile code indented like this completely.
While I don't believe that languages should unnecessarily restrict programmers, we're sometimes forced to work with such archaic languages.
In that case, you could try to write a simple pre-compiler, publish it and then never maintain it for 3 years while racking up over a hundred thousand weekly downloads on NPM.
With i18n becoming more and more important, more any more programs introduce a RTL mode in which the text changes to be aligned from right-to-left.
Maybe it's time to also make that move in the code itself and indent to the right side instead?
The main advantage of this is that the maximum line width now becomes more than a suggestion and actually has to be respected.
An often overlooked way of indentation is simply not indenting.
Has anyone ever checked if indentation actually improves readability? I know I haven't.
In fact, having no indentation forces you to read every line and ensures that you don't miss anything, reducing errors in the process.
Of course, we also save precious disk space.
What's better than no indentation?
Blank space is the
null to your empty list.
While most editors don't yet support this style, the up-and-coming OSS editor MEPaintIDE is pioneering this brand new way of styling your code.
Instead of doing the cumbersome, arduous, laborious work of inserting characters, you should take your code and push it somewhere else.
Code indented using blank space. I got a blank space, baby.
I think after this in-depth analysis we can agree that Paint is the best tool for beautiful indentation.
And I hope I could convince you that, at the very least, you shouldn't let people choose their indentation completely freely.