
Nobody talks about the real reason to use tabs over spaces - kbr
https://www.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/
======
hermitdev
Personally, I prefer hard tabs to spaces. The rationale is simple: every
single dev I've worked with has had a separate preference on how many spaces
ahould be used for an indent. I've seen 2, 3 and 4 commonly used. If you use
hard tabs, every dev can set their editor to their indentation of choice. If
you use spaces, that freedom is lost.

I say this as a currently predominantly Python dev, where spaces are
encouraged and recommended, but I disagree as stated above.

Currently, I prefer a 2 space indent after previously using a 4 space indent
for decades.

~~~
wahern
> If you use spaces, that freedom is lost.

That freedom isn't lost. As the pro-space camp is wont to point out, you're
free to pile on another layer of translation software to revert the
translation software that transformed the original tab input to a set of
spaces.

And because everybody is using programmable IDEs (or IDEs that have had all
possible programs precompiled into them), this translation will be part of
your 10MB init config file, and because it's 2019 the translation is
guaranteed to work with 100% fidelity. It's seamless!

Also, Google uses spaces, and if it's good enough for them, end of story. No
matter that KNF (kernel normal form) for Linux, Solaris, and all the BSDs uses
hard tabs, not to mention countless GNU projects. Unix developers aren't
accustomed to writing readable, shareable source code that interoperates with
a diverse set of tooling.

~~~
rendall
"Also, Google uses spaces, and if it's good enough for them, end of story"

That's no argument

EDIT: The commenter is being sarcastic. Don't downvote them :)

~~~
claytoneast
"10MB init config file" \- this is the point at which you gotta realize they
are being sarcastic.

~~~
rendall
I think you're right. I read it quickly on mobile and missed that.

------
hn_throwaway_99
Not going to get into the details of the argument (there is a reason tabs vs
spaces is considered the prototypical "religious war"), but I do strongly
disagree with the _way_ it was argued, and I felt the need to comment because
I so frequently see this type of discourse and find it very disheartening.
It's what I usually call the "If you disagree with me you want to kill
puppies" (or, in this case, "if you disagree with me you hate blind people")
form of argument. The author really isn't inviting people to challenge his
thinking with his final sentence - I feel like he's instead trying to flat out
invalidate other opinions by emphasizing how callous you must be to have them.

FWIW, I believe there _are_ other opinions that are at least worthy of
consideration, but I think other commenters have made those points as well.

~~~
em-bee
so what are your counterarguments then?

in your company code that only a known set of people need to work with, you
can choose whatever suits the group.

but in a public project, the argument that tabs help visually impaired coders
is a serious point that is hard to refute.

~~~
nexuist
Even in private company code, there may well come a day when a vision impaired
person is hired and has to work on the codebase. Even though the odds are low,
you'd be setting yourself up for long term success if you make the switch now.
Not saying that you should, just that it's always worth considering who will
end up maintaining your code after you finish working on it.

~~~
WoahNoun
See for example this blog post:

[https://blog.aboutamazon.com/working-at-amazon/blind-
since-b...](https://blog.aboutamazon.com/working-at-amazon/blind-since-birth-
writing-code-at-amazon-since-2013)

------
swsieber
Did you know that you can abuse font ligatures to have adjustable indents even
when using spaces and not tabs?

Its possible using font ligautures to turn predefined sequences of characters
into a different set of glyphs. This is usually used to display nicely joined
letters, or rendering multi-character math symbols as a nicer single wide
character. An example of the letters thing is the sequence "fi" on mac. It's
one I see on macs and in my android keyboard autocomplete.

But you can abuse it. I took a mac fixed width font and added a ligature that
turned four spaces into three spaces. And what do you know, it actually
worked. I tried it in IntelliJ and with whitespace highlighting on, it
correctly takes up 3 spaces but has 4 space markings - so IntelliJ handles it
properly.

I don't advocate this, but i would like to make a cli tool someday that lets
you take a ttf and add in whater spacing conversion ligature you want.

~~~
Gibbon1
That's disgusting and I liek lots.

Every time this subject comes up I get farther down on the opinion that not
moving forward from file formats based on what a Model 33 Teletype was capable
dealing with is a mistake that keeps on giving.

------
jchw
The knee-jerk reaction is almost certainly going to go along the lines of “But
you can emulate all of those features with spaces anyways!”

Which is true. But what if my tools don’t all do that? What if doing so makes
it harder to work for some reason or another? Users who use this tab emulation
will experience all of the downsides that spaces are supposed to avoid, like
misaligning justified comments. I think it’s a waste of effort.

All I can say is, I appreciate the Go team’s decision to use tabs. It makes
semantic sense, it puts everyone on the same playing field, and it doesn’t
require editor support. Even Windows 98 notepad can be used comfortably as a
code editor for tabs-based code, if you for some reason wanted to do that. In
reality that is not necessary or desired, but it illustrates that this is the
path of least resistance.

That web browsers handle tabs poorly is of no concern to me. If it were really
a huge problem, pretty much any editor in existence can do a Replace All to
get back perfect spaces-indented code.

~~~
runarberg
I really don’t care about tabs vs. spaces anymore. I just go with what ever my
auto formatter uses. But I do think we have been having the wrong argument all
these years, and I think the proliferation of auto formatters are setting us
straight, finally.

The issue is not tabs vs. spaces. It is block indentation vs. alignment. If
you use alignment you are forced to use monospace fonts, if you use alignment
with tabs, everyone is forced to set the same tab-stop (missing the point of
tabs).

Block indentation on the other hand allows people to use whatever font they
want (including non-monospace fonts) and what ever tab-stop they want. At that
point it doesn’t matter anymore whether the indentation is done using tabs or
spaces. The preferred font settings of the developers can deal with it.

~~~
Ygg2
To be honest using non monospace font when coding should be be fireable
offense.

I mean good luck with diffing that.

~~~
runarberg
You right. Diff tools should use fixed width characters as diff operators (em-
space, minus-sign, and plus sign are usually the same width in most fonts),
but I doubt any diff tool does. It is a shame. The only reason we use
monospace fonts as an industry is because that is how we’ve always done it,
and now we are stuck there because we fail to think out side of the box (pun
intended) when we make our tools.

~~~
Retra
Monospaced fonts are good for editing. Variable width characters are good for
quick reading because they allow you to scan past spelling errors in prose.
Monospaced fonts have distinctive 'textures' that make them amenable to
detecting symbol identity. Variable width fonts intentionally eliminate that
texture and are often optimized for ink density to 'grey out' blocks of text.
Arrow keys don't work predictably in variable width text.

~~~
runarberg
There is no reason font designers can’t create variable width font faces that
optimize character distinctions and important features while reading code.
Many font faces even have settings that allow you to opt into making
characters more distinguishable.

You are right about navigating between lines in a variable width fonts.
However that is a problem with many text boxes on the web (including slack and
github) and I don’t find it that much of a headache. I find it kind of rare
that I need to navigate between subsequent lines and maintain the column
except maybe at the start of the indentation level.

------
frereubu
One thing taught to me by an accessibility advocate in a university was that
accessibility isn't just for people who have sensory problems, Accessibility
is about making things accessible for everyone. Given that everyone seems to
prefer their own indent size, using tabs and setting the tab width in the
editor is an accessibility win for everyone, not just partially-sighted users.

I've been a proponent of spaces until now because of consistency, but this
argument has won me over to tabs.

------
alex_duf
Any visually impaired person to join the debate and help clarify?

It seems everyone is giving their opinion except the affected population.

------
Grumbledour
As a visually impaired person myself, I often find it funny that people who
are zealots about certain topics suddenly change their mind because someone
with a "disability" (Which can mean nearly anyone tbh) is affected. Its weird,
how the other humans opinion becomes suddenly more relevant because I guess
they pity them?

"I will fight Frank to the death on tabs vs. spaces, but Marry wears glasses
so she is always right!" Humans are weird.

And to weigh in on tabs vs spaces, or rather not, while I always set my
preferred tab with and use the tab key to indent, I don't know what characters
my tools insert and I don't or ever have cared.

~~~
hunter2_
If the author had written about how they used to omit alt text on all images
and explain to co-workers how it's a waste of energy because it doesn't show
up anyway, but then one day reached enlightenment about how some user agents
do use it and many people using such agents are visually impaired, and
promulgated that everyone should ensure that non-decorative, non-captioned
images have alt text, would that also be a form of pity? Are all a11y efforts
pitiful?

~~~
Grumbledour
I don't think they are, but there is a difference at not including someone and
just discomforting them.

So the guy who has his tabs set to 2 and huge font sizes, that's me, because I
am disabled, but it could also be my dad, who is just old and would want a
larger font size because its easier on the eyes. But we both would still be
able to work with bigger tabs or smaller font, it would just be annoying. But
that can be true for every coworker, so I think the disabled persons opinion
should not have more weight in such a debate.

Leaving alt tags from images makes them unusable for a screen reader though.
That argument carries more weight, because the user would not be
inconvenienced, but excluded.

And really, I am not arguing against any form of effort to make something work
good for all involved, but rather that it often seems that empathy gets only
switched on in people when someone plays a minority card. And that sucks.

~~~
hunter2_
Great answer, thank you. It seems like the accessibility bar is often
described as equal enjoyment for all, not merely attainability for all. Based
on that, I figured an inconvenience or annoyance should be below the bar, and
you are very forgiving to instead find them acceptable!

Your point about minorities is well taken, but I guess the reality is that
creating for the majority involves more obvious or ubiquitous knowledge, so
creating with minorities in mind takes more conversation, teaching, learning,
and card-like moments. Empathy in the latter but not the former is probably
innate at some level.

------
kazinator
If editors respected logical indentation levels, tabs would be more feasible.
Consider a pair of lines like:

    
    
        printk(KERN_INFO "%s: blah, blah %d\n",
               __func__, arg)
    

This will work okay like so:

    
    
        [tab][tab]printk(KERN_INFO "%s: blah, blah %d\n",
        [tab][tab]       __func__, arg)
    

If we change the tab size, the alignment is preserved.

Problem is, many editors in "mixed tabs and spaces" mode wants to fill the
second line with the maximum possible number of tabs, and minimum spaces. It
has no idea that the two belong to the same nesting level. Say that we have
four-space tabs. Then the editor does this:

    
    
        [tab][tab]printk(KERN_INFO "%s: blah, blah %d\n",
        [tab][tab][tab]   __func_, arg)
    

four of our alignment spaces turn to a tab, followed by three spaces for
alignment.

Even if your True Scotsman's editor is smarter than this, someone on the team
will use something that isn't and mess things up.

------
scalablenotions
So far, anyone who lives long enough becomes visually impaired. I hope to be
able to still code when I've very old.

------
eterm
What proponents of tabs over spaces miss is the fact that consistency is the
most important thing.

Editors ship with spaces over tabs as default, so you should use spaces over
tabs. You will be more consistent with others and reduce errors if people
somehow haven't picked up your configuration.

Anything else is just fighting the tooling.

Without consistency (hopefully brought by automation) you will find team
members struggling with merge conflicts that were unecessary and only brought
about because of whitespace changes.

Since we started forcing prettier on stage we've seen a reduction in manual
merge resolution being necessary.

And if you're using a tool anyway to apply this consistency, the decision just
becomes the following, do you use the defaults or a custom configuration? Your
life will be a lot easier if you just go along with the defaults, even if they
aren't your first preference.

That's not to say you can't custommise anything (e.g. the default line width
of 80 in prettier is too low) but you should have a very good reason to do so.
And as others have pointed out, this isn't one of them because tooling can
recognise spaces as tabs just as they recognise tabs and still adjust
accordingly.

~~~
wahern
> Editors ship with spaces over tabs as default, so you should use spaces over
> tabs. You will be more consistent with others and reduce errors if people
> somehow haven't picked up your configuration.

Actually, no, that's a very recent thing. Tabs were the default for decades in
the vast majority of editors, particularly on Unix. Even today, if I fire up
most vi implementations (I really only use nvi on BSD) tab is the default.
Pretty sure this is still the case for vim and emacs, too, and might still be
the case for other common text editors like nano.

There's no denying that spaces are far more popular now in general, but I'll
have to draw the line at whitewashing history. I haven't been programming for
nearly as long as many people here, but IME it felt like the mainstreaming of
C++, which brought the Windows/Visual Studio crowd into open source, in tandem
with Python[1], were responsible for the dominance of spaces. Even Java code
eventually capitulated, where standard practice was originally all tabs owing
to it's genesis at Sun. Unix-related software and open source was almost
entirely tabs until the early aughts. You can look at the source code
yourself, though it's not always obvious because tabs being tabs the
indentation usually looks natural regardless of your tab stop.

As I mention elsethread, Linux, all the BSDs, etc still use tabs. Projects
with a sufficiently long pedigree typically still use tabs.

(Says a user of JOE, still bitter that Joe relented and changed the default
indentation to spaces a few years ago.)

[1] I always wondered how Python ended up standardizing on spaces. I was never
into Python, but IIRC Guido preferred tabs. I'm sure there's a story behind
it, and have an inkling it's related to the onslaught of developers who cut
their teeth in the Windows ecosystem.

~~~
eterm
I'm not "whitewashing history" that's a bizarre accusation because I'm not
talking about history, I'm talking about what you should use today.

Just because tabs would have been the right choice in the past doesn't make it
the right choice today.

------
th0ma5
I wouldn't necessarily recommend jEdit, but I'm sure a lot of editors have a
soft tabs feature like it. And with linters I can't imagine you couldn't just
run your local fork with which ever have the integration make the production
version be which ever. Anyway... I personally don't care what you do so long
as you try to do the simplest and least and obvious thing.

~~~
runarberg
Exactly. I think this debate is kind of outdated, we have tools now to deal
with stuff like this. Even the OP argument of the visually impaired doesn’t
really matter as long as you set your auto formatted to use block indentation
and no alignment (sorry gofmt!). Just use a font face the smooshes the
whitespace together if you need small indentation with a large font size, or
one that draws it out if you need to exaggerate it.

------
Glyptodon
So one thing I've wondered for a while is why every single non-public tab-
indented project I've ever had to join (as opposed to create) has been a
disaster from a consistent code formatting perspective.

~~~
flukus
My experience is the opposite. When a project is tab indented and you have 1
guy indenting by 2 spaces and another by 4 the inconsistency is spotted pretty
quickly, maybe this is what you're noticing?. When spaces are used it's easy
for tabs to hide.

Also there's a lot of crappy editors that don't handle smart tabs well,
including some big, expensive, proprietary IDE's.

~~~
Glyptodon
I'm guessing at least part of it is different smart tab behavior, but I've
opened files to find chunks that were indented with double tabs (as in one
indent level was done as two tabs) in the middle files that were otherwise
single tab indented and even weirder stuff that I suspect is because of
somebody indenting wrapped text.

(Yes, poor QC and Dev ops went along with it.)

------
andy_ppp
My take: whatever the project is currently using, spaces or tabs, please keep
it that way. You might think this is important but really you can find
arguments for either way, consistency trumps everything.

------
NikkiA
I recently contributed to a GPL project that uses tabs+spaces, but I have
emacs configured to not use tabs ever, at all.

After the first git commit it was obvious that this was going to be a problem,
the diff lines didn't match at all.

So I'm seriously considering, after 38 years of being a die-hard 'spaces or
death!' user to switch to using tabs with my tab-stop size configured to match
my spaces preference.

------
quickthrower2
I was a tabs guy but now I’ve made peace with spaces. Honestly any IDE
including low touch ones like Vim will auto indent for you anyway.

------
amanzi
I don't have a strong opinion on this long-running debate, but the example
given sounds like a valid argument.

I just changed my VS Code settings to not insert spaces when pressing tab
("editor.insertSpaces": false) and will see how it goes. Being able to change
the tab size ("editor.tabSize": 4) already seems like a neat feature that will
come in useful.

------
Grue3
Well, Lisp code can't be properly indented with just tabs. So tough luck, I
guess? Why wouldn't editors programmers use allow to customize indentation
space size instead? So you could set up each indentation space = 2 characters
and get huge indents. Or set it to 1/2 character and get tiny indents. Seems
easy to implement in e.g. Emacs.

~~~
taeric
Why can't it? Fixed width tabs, sure, but tab stops would work fine.

It is more work in the editor, so I don't expect it anytime soon. Especially
not with consistency. But it is doable.

------
Stratoscope
What most of these discussions leave out is that you can't just say "use
spaces instead of tabs."

You have to say _how many_ spaces.

Is it 2? 3? 4? 8? How many?

If you use spaces, you are committing to say how many will represent one
indent. And please take note of how your choice affects the visually impaired
programmers from the Reddit thread. Or someone like me who finds monospaced
fonts hard to read and proportional fonts much more legible.

But why do you even need to say this? Why should it matter how many spaces
represent an indent level?

The only time it really matters is when you not only use indentation, you use
_column alignment_ , like this:

    
    
      myFunctionThatDoesStuff(someArgument,
                              andThisCalculatedOne(anArgumentThatMeansSomething,
                                                   anotherWordyName));
    

This style is mandated by many coding standards, including Google's C++
standard. If you use an alignment-based style, you had better use spaces, or
else you are in the "tabs for indentation, spaces for alignment" muddle.

What would happen if you abandon column alignment and use only indentation:

    
    
      myFunctionThatDoesStuff(
          someArgument,
          andThisCalculatedOne(
              anArgumentThatMeansSomething,
              anotherWordyName
          )
      );
    

Here the parentheses are treated just like curly braces: if you need to line
stuff up, don't do it at whatever column things happened to fall on, do it by
indentation only. That's how we code curly brace blocks.

Now your code will be just as readable if it's indented with tabs, or with
whatever number of spaces you like.

If we coded curly brace blocks the way these standards require us to use
parenthesized expressions, our code would end up looking like this:

    
    
      if(someBooleanExpression) {someFunctionCall();
                                 if(anotherBooleanExpression) {doSomething();
                                                               doAnotherThing();}}
    

Do you code like that? Do you _want_ to code like that? Then why do you format
code like that (if you do) simply because the delimiters happen to be
parentheses instead of curly braces?

If you stop using column alignment, and start using indentation instead, so
many problems go away. Space indentation (and how many spaces?) no longer has
any advantage over tabs.

I sometimes wonder why so many coding standards mandate column alignment. I
think it is because people get tired of talking about it and say "we must
agree on _something_ , now! And we will stick with it forever."

I've been in these discussions, and what happens is whoever is most
"passionate" about their particular style gets their way. And that will
usually be the person who is fussiest about these things, the person who loves
fiddly column alignment. Why else would such an impractical approach be baked
into so many coding standards?

~~~
kazinator
Tabs could plausibly work if the editors were smart enough to treat this:

    
    
        myFunctionThatDoesStuff(someArgument,
                                andThisCalculatedOne(anArgumentThatMeansSomething,
                                                     anotherWordyName));
    

as being all at the same indentation level. If this is at indentation level 2
then all these lines should start with two tabs. All whitespace after those
tabs should be spaces. Then you can adjust the tab size without spoiling the
relative alignment.

The editor has to understand the language fairly well. (In the case of C or
C++, it also has to recognize preprocessor lines and treat them specially, as
well as certain elements like goto labels that are out of indentation.)

It won't work in Lisps, because in Lisp, nested expressions have their own
internal indentation which can be relative to alignment:

    
    
      (long-function-name (lambda (arg)
                            (aligned ...)
                            (stuff ...)))
    

Basically the only thing that could work 100% would be the original
typewriter/TTY/terminal concept of movable tab stops. The editor would grok
each expression, and then set up custom tab stops for each line individually:

    
    
      (long-function-name (lambda (arg)
                            (let ((var ...))
                              (stuff arg arg
      v                   v v v      v
                                     arg))))
    

The v's indicate the tab stops for the last line, so five tabs are used. The
algorithm for discovering these tab stops doesn't seem overly complicated. We
shoot a ray upward at column zero. Whatever it intersects with is the anchor
line. We then look for the first tab stops in the anchor line by moving the
vertical ray. By this process we discover the ( in (long-function-name, and
the ( on (lambda. After that, our vertical hit test encounters the (let line,
so that yields a tab stop. If that weren't there, then the (arg) would be the
next stop.

Basically tabs should intelligently be based on preceding material, as if an
invisible helper were setting tab stops on our typewriter.

One problem with this is that any piece of software that has to format the
code has to implement the same thing, exactly.

------
Stratoscope
Meta: I am curious why this suddenly dropped off the home page and down to
around #98. It can't be the upvote-to-comment ratio, as there are 85 up votes
and 43 comments. Was it a manual intervention?

~~~
kazinator
Someone just set the vertical indent (form feed character) to 90 lines. It
supposedly helps the humor-impaired.

------
scarejunba
Has more energy ever been expended more often for less gain than this debate?
It is truly the most well-painted of bike sheds.

~~~
koala_man
I didn't think there'd ever be anything new in this debate, but this is the
first time I've heard the accessibility argument.

------
mikorym
I don't see why people spend time on this. Someone mentioned recently (or
maybe I dreamt this) that programming is really, really much more about the
specification than the implementation. If your specification is done
flawlessly, then the implementation follows from that. I had the idea a while
ago of starting a alternative to Excel and then I realised it would be way
more useful to simply _document_ Excel's behavior.

~~~
flukus
> I don't see why people spend time on this.

Because control freaks still can't accept personal preferences and insist on
uniformity, the idea that I won't indentation to look slightly different on my
computer than it does on there's is a heresy. If they world were up to them
they'd enforce other things like editor schemes, in fact some have tried to:
[https://vim.fandom.com/wiki/Modeline_magic](https://vim.fandom.com/wiki/Modeline_magic)

First shalt thou press the Holy Tab. Then, shalt thou space to three. No more.
No less. Three shalt be the number thou shalt space, and the number of the
spacing shall be three. Four shalt thou not space, nor either space thou two,
excepting that thou then proceed to three. Five is right out. Once the number
three, being the third number, be reached, then, writest thou thy Holy code.

~~~
kazinator
The last thing we want is control freaks preparing instructions for machines
to execute.

Control freaks should be in politics, management, education, nursing and such,
and stay the hell out of software.

------
shitgoose
click click click click click click click click vs tab

sounds like a perfect embodiment of modern software development style.

~~~
Sharparam
Do you seriously believe people are manually pressing the spacebar to indent
with spaces, or are you trying to make a joke?

