Tabs are objectively better than spaces(gomakethings.com)
gomakethings.com
Tabs are objectively better than spaces
https://gomakethings.com/tabs-are-objectively-better-than-spaces/
6 comments
Did you read the article? This is the point, or rather the inverse. Why do you need the code to look the same on your machine as on mine? So what if I prefer wider indents? Tabs allow flexibility of viewing experience while keeping the code itself consistent.
Editors are smart enough now that they can format the code for display however you like, independently of tabs vs. spaces.
Oh I read it, doesn't mean I agree.
It matters in that the code you write looks great for you, but misaligned for everyone else.
If we are coding as a team, the code needs to be easily readable by everyone, not just by your IDE -- and without having to change my IDE to suit each developer's personal preference of tab size
It matters in that the code you write looks great for you, but misaligned for everyone else.
If we are coding as a team, the code needs to be easily readable by everyone, not just by your IDE -- and without having to change my IDE to suit each developer's personal preference of tab size
I honestly don't understand what you mean by "without having to change my IDE ...".
Because that's exactly it -- you set your IDE to make tabs the width that is easy to read for you. I do the same. We both get readable-to-us code without imposing our visual preference on each other.
I don't understand the downside of this approach. Am I just missing something obvious? Honestly asking.
Because that's exactly it -- you set your IDE to make tabs the width that is easy to read for you. I do the same. We both get readable-to-us code without imposing our visual preference on each other.
I don't understand the downside of this approach. Am I just missing something obvious? Honestly asking.
I have always loved tabs, but the general consensus and insistence that Spaces are the Way(tm) has made me switch begrudgingly because I want to be a good team player.
I love that I can set tabs to a certain size and it all just works. Nowadays I have to use an editor that already has spaces in mind just to edit. I used to be able to edit code in Notepad, but with some codebases using 2 spaces, or 4 spaces... I've even seen some with 8 (!!).. I have to use an editor that understands spaces = tabs (VS Code, for example).
There are days when I want to switch sizes, just because of my little neurodivergent brain.
I'd love to hear why spaces became the dominant form of indenting code. Does anyone know the history?
I love that I can set tabs to a certain size and it all just works. Nowadays I have to use an editor that already has spaces in mind just to edit. I used to be able to edit code in Notepad, but with some codebases using 2 spaces, or 4 spaces... I've even seen some with 8 (!!).. I have to use an editor that understands spaces = tabs (VS Code, for example).
There are days when I want to switch sizes, just because of my little neurodivergent brain.
I'd love to hear why spaces became the dominant form of indenting code. Does anyone know the history?
The implication in the article and your comment is that tabs let you switch indentation level without any negative consequences. But that’s clearly false.
A lot of code will use space to align code over multiple lines. If you only use tabs, the alignment will be broken in other developers editors if they don’t have the same tab indentation.
The author complains about visual noise with 2 level indentation. But misaligned code can become a complete unreadable mess. You end up being forced to set your tab indentation to the same value as the original author anyway.
So the logical conclusion then may be to use tabs for indentation and spaces for alignment. That would work in theory, but handling that correctly in an editor is nearly impossible.
So then you end up with the conclusion that spaces is the only way that doesn’t have any serious downsides. It’s far from ideal, but i don’t think the purported benefits that tabs have of letting you change indentation later works in practice anyway.
I’ve experienced this personally in a huge code base with multiple authors where some earlier code used tabs. It was always a 50% chance that code with tabs looked like hot garbage as the author had a different tab level than yours. After enforcing using only spaces, at least the code looks fairly organised most of the time.
A lot of code will use space to align code over multiple lines. If you only use tabs, the alignment will be broken in other developers editors if they don’t have the same tab indentation.
The author complains about visual noise with 2 level indentation. But misaligned code can become a complete unreadable mess. You end up being forced to set your tab indentation to the same value as the original author anyway.
So the logical conclusion then may be to use tabs for indentation and spaces for alignment. That would work in theory, but handling that correctly in an editor is nearly impossible.
So then you end up with the conclusion that spaces is the only way that doesn’t have any serious downsides. It’s far from ideal, but i don’t think the purported benefits that tabs have of letting you change indentation later works in practice anyway.
I’ve experienced this personally in a huge code base with multiple authors where some earlier code used tabs. It was always a 50% chance that code with tabs looked like hot garbage as the author had a different tab level than yours. After enforcing using only spaces, at least the code looks fairly organised most of the time.
I don't understand what you mean. Is this an IDE thing? Do you mean the IDE/editor is auto-wrapping long lines (visually)? If not, why would manually indented lines not also use tabs if tabs were the standard?
> I'd love to hear why spaces became the dominant form of indenting code. Does anyone know the history?
My take is it's because when people use tabs, they don't only use it for "regular" code indentation, which remains consistent when different people configure their editor for a different visual tab width. They also use it for things intended to line up, like this:
But the lines 3 and 5 are intended to match up with the expression, and that breaks when someone has used tabs (followed by a few spaces).
Changing displayed tab width makes lines like that misaligned and ugly. Even worse, it does so in an inconsistent way in different places in the code. If the example was written with 4-wide tabs (matching the regular indent on line 2), then you display it with 2-wide tabs, it will change the line 3 and 5 indentation inconsistently:
This messy repo problem is avoided by mandating spaces.
On the face of it, this seems to take away your personal flexibility to change visual indentation locally. But this isn't really true. In principle, your editor could change how it displays the code, as if those spaces were really the equivalent tabs, and then use a different displayed tab width, distinguishing between regular and expression indentation in the editor to keep various alignments.
My take is it's because when people use tabs, they don't only use it for "regular" code indentation, which remains consistent when different people configure their editor for a different visual tab width. They also use it for things intended to line up, like this:
void actions() {
int bat = (get_bat_thing()
+ the_other_thing());
int turn = (get_turn_thing()
+ the_other_thing());
return bat + turn;
}
But the lines 3 and 5 are intended to match up with the expression, and that breaks when someone has used tabs (followed by a few spaces).
Changing displayed tab width makes lines like that misaligned and ugly. Even worse, it does so in an inconsistent way in different places in the code. If the example was written with 4-wide tabs (matching the regular indent on line 2), then you display it with 2-wide tabs, it will change the line 3 and 5 indentation inconsistently:
void actions() {
int bat = (get_bat_thing()
+ the_other_thing());
int turn = (get_turn_thing()
+ the_other_thing());
return bat + turn;
}
This messy repo problem is avoided by mandating spaces.
On the face of it, this seems to take away your personal flexibility to change visual indentation locally. But this isn't really true. In principle, your editor could change how it displays the code, as if those spaces were really the equivalent tabs, and then use a different displayed tab width, distinguishing between regular and expression indentation in the editor to keep various alignments.
I can see that in the examples you have given, where tabs might not be desirable. I dislike doing the manual alignment of code across multiple lines, anyways, so maybe that is why I haven't really come across it in my own code. If it doesn't fit in a single line neatly, I try to rewrite it so that it does... but I can understand this isn't always possible.
Some people indent in a way that breaks with tabs. Like:
object1.field1 = value1;
longObject2.field3 = value2;
longObject23.longField1 = value3;
if ((firstArg == 1 && x == 3)
|| (firstArg == sthElse && x == 4)
|| (thirdArg == 3 && fourthArg == 2)
) { ... }You do the indenting with tabs and the layout with spaces. Then it doesn't break
Yes that works. Until a variable name changes which could cause the alignment to cross a tab boundary so then instead of just fixing the alignment with spaces you have to convert existing spaces to tabs and realign.
It's just more work and to do it reliably requires making tabs visible in the editor though, which is another mark against tabs for many, I'd imagine.
I suppose there may be Vim/Emacs realignment macros that take care of it but then we're heading toward the other classic argument.
It's just more work and to do it reliably requires making tabs visible in the editor though, which is another mark against tabs for many, I'd imagine.
I suppose there may be Vim/Emacs realignment macros that take care of it but then we're heading toward the other classic argument.
I think we're talking about different things. The rule is: nothing should appear to the left of your tabs - use spaces everywhere else.
Here's what it should look like (if you really want to go full-alignment):
Here's what it should look like (if you really want to go full-alignment):
class Demo {
\tfunction thing() {
\t\tlet height = 123;
\t\tlet width = 456;
\t\tlet title = "Foo";
\t\tlet description = "Foo bar baz";
\t}
}I was reading in an app (Materialistic) and none of that spacing rendered so I was confused. But I see it on the web.
Personally, I really hate code formatted like this. I don't really think it's any easier to read, and I find it obnoxious to write/maintain unless the editor does it for you. Just my opinion.
Personally, I really hate code formatted like this. I don't really think it's any easier to read, and I find it obnoxious to write/maintain unless the editor does it for you. Just my opinion.
I just don't indent code like that, but I understand now that others might - and in that case, tab alignment isn't always desirable.
Jamie Zawinski was an influential programming author 25 years ago.
https://www.jwz.org/doc/tabs-vs-spaces.html
https://www.jwz.org/doc/tabs-vs-spaces.html
I have ADHD and letting ppl define how much indent they have equals to not having a standard. Some will choose 3 and you will curse them for life. 4 spaces is the only way, rest sbould be burnt in hell.
The ones who choose 3 are the peacemakers--annoy the 2's and 4's equally.
Betamax was also objectively better than VHS.
There is added value to collectively agreeing on one format. I think that added value can easily outperform the technical merits of a specific format.
There is added value to collectively agreeing on one format. I think that added value can easily outperform the technical merits of a specific format.
> Betamax was also objectively better than VHS.
No, Betamax was worse for most uses than VHS. The picture quality of Betamax was better at roughly the same tape speed, but the cassettes held about half the amount of tape. Slowing down the tape to improve capacity made the quality advantage go away.
No, Betamax was worse for most uses than VHS. The picture quality of Betamax was better at roughly the same tape speed, but the cassettes held about half the amount of tape. Slowing down the tape to improve capacity made the quality advantage go away.
Use an autoformatter with formatting rules defined and committed with the code so your team never has to argue about code style again. It shouldn't even be possible for that to come up in code review since it should be an automated check.
Monospace spaces are consistent across every machine
While the fight over "how many spaces" can be tricky, at least the code looks consistent once a standard is found