
Nobody talks about the real reason to use Tabs over Spaces - pagade
https://reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs
======
Sahhaese
We discussed this 5 days ago:

[https://news.ycombinator.com/item?id=20341354](https://news.ycombinator.com/item?id=20341354)

~~~
yitchelle
@dang, for dupe submission, is it possible to merge the comments from later
submission into the initial submission?

~~~
dang
We do that, but usually only when the two threads were concurrent. Five days
is probably too much of a stretch.

------
scrollaway
Been saying for years that tabs are an accessibility feature. It's good to see
a thread get some traction. I've never understood why people -- logical
people; programmers -- are so religious about spaces, especially in the Python
community.

A while back I tried to make the case to the author of Black (The python
community's excellent auto-formatter) to add a "\--use-tabs" option. I was not
successful; I had to fork Black to be able to use it.
[https://github.com/jleclanche/tan](https://github.com/jleclanche/tan)

~~~
dTal
My impression is that many people are not confident in their understanding of
tab behavior; there's a perception of them being weird, unpredictable voodoo
(as exemplified by comments which imply that many programs don't support tabs
well, despite that virtually all programs support tabs flawlessly, right down
to notepad and standard GUI toolkit textboxes.)

I think this stems from a broken mental model, whereby tabs are regarded as
"representing x number of spaces", where x is some unknown variable in the
editor of whoever created the file. These people say things like "tabs are
just a compression mechanism" and "tabs are inconsistent across editors". In
the minds of these people, spaces have primacy, and tabs are just weird
inconsistent not-spaces that catch you out.

The proper mental model, of course, is to recognize that tabs don't represent
any number of spaces - they represent indents, and that's that. You could
quite happily set your editor to display tabs as indents π spaces wide. It is
an error on the part of the person writing the file to assume any particular
tab width.

There are a few coding style conventions that break the assumption that the
indentation should strictly reflect the nesting depth, like breaking up a long
argument list over multiple lines and trying to line the second line up with
the opening parentheses. In my view these are bad coding styles anyway and
should be retired.

~~~
rocqua
The issue with tabs as indent level is that there are two reasons to indent.
The first is for logical scoping, where tabs do indeed make sense. An example
would be

    
    
        int main(void){
            indentedStatement()
        }
    

However, the second is for aligning multi-line statements. Something like:

    
    
        int main(void){
            foo(bar,
                baz,
                54
            );
        }
    

Here, the indenting on arguments baz and 54 really should be aligned with the
argument bar. If we really want to combine both use-cases that involves a mix
of tabs and spaces. Tabs fist for getting the number of nested scopes, with
optionally spaces to align text.

Meanwhile, mixing tabs and spaces is almost universally seen as bad. This
makes sense because it is not visible where the tabs end and spaces start.
This can easily lead to inconsistencies that are invisible to a writer, but
are horrible for a reader with a different tab representation.

If you believe that indenting like this is a bad coding style, how do you
suggest those statements should be formatted?

~~~
colanderman
The solution is to mix tabs and spaces; most editors can be configured to
clearly show tabs. Indent with tabs, then align with spaces. Never place a tab
after a space.

If you mess up, no big problem, someone else will see it and fix it. People
screw up space-alignment all the time anyway.

Or, better still, don't visually align stuff. It's annoying as hell to
maintain unless you use an IDE, and has a tendency to bunch stuff up toward
the right margin when function names grow long. Just start the argument list
indented by one tab stop on the next line. More visually consistent too.

------
dTal
The reason it's more accessible is because it's The Right Way, in the same way
that a text file is more accessible than a screenshot of that text file.
Indentation is a _semantic_ property, not a visual one.

~~~
viraptor
> Indentation is a semantic property, not a visual one.

Depending on style in can be both.

    
    
        +-- semantic
        v
        def something(with aligned,
                      list of,
                      parameters):
                     ^
            visual --+

~~~
scrollaway
Oh gods please don't align like this, it's just so unreadable.

Example of what that does in practice: Lines that end up wrapping almost at
the end of the soft-character-limit and look like this:

[https://github.com/pennersr/django-
allauth/blob/c9b31ddee81d...](https://github.com/pennersr/django-
allauth/blob/c9b31ddee81d2cde06c1f686c4eb7703f916681f/allauth/account/views.py#L629-L632)

~~~
skohan
IMO it depends on the language. With named parameters it is very readable, and
is my preference when you have functions with lots of parameters.

~~~
dTal
It breaks a fundamental assumption, which is that indent depth strictly
reflects code nesting depth.

If you're going to do that, the "correct" way would be to indent each
parameter with tabs to the same depth as the function declaration, and then
use spaces to take up the rest of the space (i.e. the width of the function
declaration). Which is admittedly ugly - but it's ugly because it reflects the
ugliness of misusing indentation for alignment. It's slightly less ugly if you
use an editor that displays tabs and spaces differently - Kate/Kdevelop use a
nice discreet » character for each level of indentation:

    
    
      def hello_spam():
      »   while True:
      »   »   print ("Hello",
      »   »          "World")
    

The last line is visually aligned, but the semantic depth is the same.

~~~
11235813213455
I'd go with

    
    
      def hello_spam():
      »   while True:
      »   »   print(
      »   »   »   "Hello",
      »   »   »   "World"
      »   »   )

------
maskros
I've been a tab user since forever. The biggest issue with using spaces is not
how much you indent, it's the bad pattern of aligning stuff vertically beyond
a simple N-level indent.

Using spaces to align stuff on multiple lines causes multiple problems.

Any changes will affect surrounding lines. This adds busy-work to realign
everything, especially if you're not using a fancy editor plugin to do it. It
also makes for bigger diffs, which add pointless noise when reading diffs, and
potentially unneccessary merge/rebase conflicts.

It's also assuming that the text is displayed in a monospaced font. A (very
rare) few of us like to code with good looking proportianally spaced fonts
instead of awkwardly spaced typewriter fonts.

------
mstade
I've been a die hard 2-space indent person for well over a decade, but this is
an argument I simply can't ignore and I feel compelled to reconsider my
position. Thanks for sharing this!

~~~
Pyxl101
Here’s another argument:

If everyone uses tabs for indentation, then you can configure your editor to
display that as 2 characters width, while the people who prefer 4 or 8 can do
the same. No one needs to argue about how many columns of indentation there
will be (1/2/4/8) since it’s specified in text semantically and displayed
individually. No one needs to be die-hard N-space-ists since everyone can have
their way simultaneously. Even code that wasn’t written by people who prefer
your 2-column indent style (if they would otherwise be using spaces) will look
that way to you. Everyone wins!

~~~
vanderZwan
> _(1 /2/4/8)_

Sometimes I wonder if I'm the only person in the world with a preference for
3-character width tabs.

I also wonder if I can ever bring up this topic in public without being called
perverse by other programmers. People get _really weirdly_ religious about
this.

~~~
bananicorn
Oh, how come?

What language are you using where 3-spaces-wide tabs are more comfortable?

~~~
billforsternz
An indentation preference can be largely language independent.

~~~
dkersten
Can be and probably usually is. However, funnily enough, I have a language-
dependent preference: 2 spaces or Lisp-like languages, 4 spaces for all
others.

------
toyg
I used to be a “tab person” when I started using python in 2001 - after all,
it makes more logical sense and it saves bytes, what’s not to like?

And then the world duly standardized on 4-spaces-per-indent.

So I’ve long given up and just gone with the flow. Unless big projects switch
to tabs in a coordinated manner, to make a big statement, this matter is
unlikely to ever be reevaluated.

~~~
yitchelle
Would be interesting to see a table of spaces per indent vs language or
Project.

I know the Linux kernel has an 8 spaces requirement. Code has been known to be
rejected based on this violation.

~~~
silon42
Linux kernel has 1 tab, which many/most would map to 8 (including me). Mapping
to 8 has (and not 2 and 4) becomes relevant if you have line size limits.

~~~
C1sc0cat
That struck me as odd surely 8 is the norm - a holdover from typewriters

------
mojuba
That's a very good argument, but I have another one, also often dismissed: if
you navigate using your keyboard's arrow keys (which can be more productive
than mouse/trackpad) then jumping over tabs to reach text is just way faster.
Spaces kind of force you to use your mouse more.

~~~
xiwenc
Assuming you're not using some very basic text editor; good ones have skip
word. For instance 'w' in vim, or 'ctrl + right' in vscode.

~~~
mojuba
True, but nothing is simpler than an arrow key.

~~~
pieix
This is not really true; ‘w’ is one row up from the home row and is easily
accessible with the middle or ring finger. An arrow key is a hand-shift or an
awkward pinky stretch away. Vim keybindings were explicitly designed to be
simpler than arrow keys once you’ve gotten over the learning curve.

~~~
mojuba
Unfortunately vim is not very useful for coding and debugging iOS apps. Or
Android, or Windows for that matter.

~~~
organsnyder
I haven't done any iOS development, so perhaps I'm expecting too much; but
surely there is an IDE that has a vim-mode plugin? Every IDE/editor I've
used—all JetBrains products, Atom, Visual Studio, Eclipse...—has a vim plugin
readily available. They're rarely perfect (they tend to behave weirdly with
IDE autocompletion and the like), but they're more than adequate for basic
text navigation.

~~~
mojuba
> but they're more than adequate for basic text navigation

I really think basic text navigation is no longer a problem since the the
adoption of PC keyboards in the 1980s and 1990s. Key arrows are easy to find
blindly except maybe on some screwed up laptop designs.

~~~
organsnyder
Perhaps our definitions of "basic text navigation" are different. I'd include
capabilities such as "jump six words to the right, based on natural word
boundaries" and "jump six words to the right, based on whitespace only". Oh,
and "jump to the end of this statement that's enclosed by parentheses".

Not trying to start a vim-vs-whatever war here, though I suppose that's
inevitable in a discussion of tabs-vs-spaces...

------
enriquto
I do not really care for tabs vs spaces, _except_ in Python, where tabs are
obviously the appropriate choice. For conceptual simplicity and orthogonality,
if you want to treat python programs as text files, and deal with them using
standard text processing tools, it is much more comfortable when the
indentation is marked by a single character.

Apart from that, I never cared if people used spaces in other programming
languages (as long as it was 8 spaces per level, of course). But this reddit
post highlights an important reason to promote tabs everywhere, not only in
Python.

~~~
IshKebab
Do you actually use 8 space indents??

~~~
enriquto
Of course; I am a decent person. Let me just quote Linus Torvalds here:

> Tabs are 8 characters, and thus indentations are also 8 characters. There
> are heretic movements that try to make indentations 4 (or even 2!)
> characters deep, and that is akin to trying to define the value of PI to be
> 3.

------
userbinator
_these guys have serious problems using codebases with spaces, they have to
convert, do their work, and then unconvert before committing_

I used to work for a company that had automatic formatting on checkin/checkout
--- everyone had his/her own formatting preferences (tabs/spaces and how many
was one of them), which deviated slightly from the "official" one, but the
process was basically completely automatic.

My personal preference is _one_ space --- files are just as small as with
tabs, and the column counter of the editor also directly corresponds to the
indent level.

Also, the lack of capitalisation and run-on sentences in a post arguing about
accessibility is a bit ironic.

------
_ZeD_
I cannot suggest enough to avoid this debate and pass to elastic tabstops

[http://nickgravgaard.com/elastic-tabstops/](http://nickgravgaard.com/elastic-
tabstops/)

~~~
daghoidahl
I agree completely. Elastic tabstops are such an elegant solution to the whole
debate. It turns the tab character into what it should be semantically, a
character to denote alignment, just as it is used in a wysiwyg word processor.

When supported by the editor, it also allows the user to align columns using a
proportional font instead of the fixed-with fonts we have to use now.

The concept has been discussed on HN earlier, but the accessibility argument
is something that I hadn't considered or seen anyone discuss.

~~~
afiori
Why is this dead? It provides a commentary on the feature linked.

------
JacKTrocinskI
Use tabs for indentation, space for alignment, why do it anyway else?

I especially like Linus Torvalds view on indentation:

 _" Tabs are 8 characters, and thus indentations are also 8 characters. There
are heretic movements that try to make indentations 4 (or even 2!) characters
deep, and that is akin to trying to define the value of PI to be 3.

Rationale: The whole idea behind indentation is to clearly define where a
block of control starts and ends. Especially when you've been looking at your
screen for 20 straight hours, you'll find it a lot easier to see how the
indentation works if you have large indentations.

Now, some people will claim that having 8-character indentations makes the
code move too far to the right, and makes it hard to read on a 80-character
terminal screen. The answer to that is that if you need more than 3 levels of
indentation, you're screwed anyway, and should fix your program."_

[https://github.com/torvalds/linux/blob/master/Documentation/...](https://github.com/torvalds/linux/blob/master/Documentation/process/coding-
style.rst)

------
harimau777
Something that I feel gets overlooked in tabs versus spaces is that a tab
generally has a specific semantic meaning (increase indent by one) whereas a
space's meaning depends on how many spaces you are using to indent and a
single space has no meaning on its own (unless you are indenting using only
one space).

As a side note: I wish that JavaScript had a utility like the "indent" utility
in Unix for precisely styling C code. Prettier is close; however, it cannot be
customized in the detail that I would like.

~~~
thiht
> however, it cannot be customized in the detail that I would like

That's the whole point. Why is what you want better than what the formatter
says?

~~~
harimau777
I don't mean customized by an individual user, I mean customized by the team
to fit their style guidelines.

------
curiousgal
This is a decent argument but calling it "the real reason" takes away from it.

------
devit
Yes, it's pretty obvious that Tab is correct since it has semantic meaning
(tab = indent), is one character and has configurable width.

------
billpg
I kind of feel that source code needs to take a tip from HTML and apply a
style-sheet. Have editors parse the code and display according to the user's
preferences.

~~~
kranner
Exactly. Maybe a browser extension to pretty-print spaces to tabs, or sites
like Github/SO can offer a built-in option.

~~~
billpg
I'd go even farther than that. Prefer {}, BEGIN/END or indented code? Prefer
&& and || or AND and OR? Prefer infix a+b+c or LISP style +(a,b,c)?

Pick one and the editor will show and edit code that way. The underlying code
files remain unchanged.

~~~
kranner
Wouldn't LISP style be (+ a b c) though?

~~~
billpg
You may be right. I don't actually know LISP.

------
ablomen
I totally agree, as a dyslexic big pieces of text look like a garbled mess. I
need > 2 spaces to be able to navigate a file with code with any speed.

Tabs for indentation, spaces for alignment looks to me like the best of both
worlds.

~~~
C1sc0cat
The problem I have (also a dyslexic) with tabs vs spaces is you cant (normaly)
see tabs.

The old school 80 column fixed layouts like Fortran had did have its
advantages.

~~~
enriquto
> The problem I have (also a dyslexic) with tabs vs spaces is you cant
> (normaly) see tabs.

There is probably no editor program in your computer right now that is not
able to display tabs visually.

~~~
C1sc0cat
Yes I know but I am not working with with those fugly show white space
settings turned on.

Like one of the previous commentators I am a dyslexic and I find displayed
tabs CR etc very visually distracting

~~~
carlmr
VSCode doesn't display the CR and with the boundary setting doesn't show
whitespace when it's a single space between words.

------
endorphone
Tabs v spaces should be an argument that we are long past by now, our editors
no longer bound by the limits that once fueled such arguments.

Your editor should automatically purge all whitespace and format according to
your settings and language canonical form. Whether tabs, spaces, curly braces
on the end of line or next line, and on and on.

Go coming with go fmt is one of the great things about the language because
instantly so many color of the shed arguments were vanquished.

------
gopiandcode
I generally don't like using tabs, as I find having two characters for
whitespace leads to annoying inconsistencies. However, were a team member
request I use tabs for accessibility reasons, I would have no issue complying.

That aside, I don't feel that this particular argument any stronger than any
personal preference, let alone some kind of be-all final reason.

Generally whenever more than one space is used consecutively it is intended
for indentation purposes - thus an equivalent solution to the accessibility
problem is to just configure the editor to render consecutive spaces
differently.

The post author calls for more editors to support adjusting tab widths showing
that using tabs isn't automatically an accessibility win - spaces users could
just as easily call for more editors to support custom ligatures to help the
visually impaired.

~~~
skohan
I actually find having a separate character for indentation is a strength of
tabs rather than a detriment. Tabs tell you how the lines in your program
relate to one another, and spaces tell you how things relate within a given
line.

On top of that, I think the strongest argument for tabs is efficiency. space-
indented code uses 3 times as many bytes to represent a level of indentation
than tab-delimited code. That might not seem like a lot, but spread over all
the commits in all the codebases using spaces, it seems pointless to use all
that extra disk space for no reason.

I think the real problem is that the default tab width for web interfaces is 8
spaces. If it were a more reasonable 4 characters wide, I doubt it would even
be an issue.

------
childintime
Despite adding a valid perspective, this is mostly clickbait.

A file is just a storage format. The real issue is that IDE's don't render
files according to user preferences, be them TABs or spaces, or PascalCase vs
snake-case. When saving they convert back. No need to "get everybody on the
same page" and in the process create winners and losers.

Unlike laws (or like laws), technology has the capacity to create win-win
situations. This is a good example. So the real question is why we insist on
debates, instead of actually doing our jobs. Congress can only solve so much.

------
undecisive
That is a pretty good point. As a rubyist, I always use and advocate two
spaces - but if I ever find myself on a team with visual impairments, I'll be
sure to ask whether tabs would be useful to the team. I'm a big believer that
Team-level consistency is far more important than Universe-level consistency,
and silver bullets kill.

That said, I'm intrigued - surely this must be a solved problem at this point?
Anybody aware of any good text editors / editor plugins that allow you to
modify the visual spacing of start-of-line spaces?

~~~
dTal
It is a solved problem! Just use tabs. Almost every editor supports
adjustable-width tabs. Why go out of your way to avoid tabs, and then make
spaces behave like tabs?

------
mcv
An excellent argument. I've been mostly agnostic about the tabs-vs-spaces
debate, as long as we just pick one and stick with it everywhere consistently
and never ever mix the two. I've had this feeling lately that maybe tabs might
be more appropriate than spaces, but never felt strongly about it, and
everybody has settled on spaces, so lets just stick with that.

But in light of this argument, yes, lets move to tabs instead. More control
for the user in how you actually display them.

------
zimbatm
Nobody talks about the fact that git can convert tabs to spaces and vice-versa
on the fly so the whole discussion is irrelevant :-)

[https://stackoverflow.com/a/2316728](https://stackoverflow.com/a/2316728)

------
coldtea
> _one of them uses tab-width 1 because he uses such a gigantic font-size_

But if they use a "giganting font-size" to see the letters, spaces would still
be proportionally gigantic. Why would they need to have custom indent size,
since everything will play along with their font-size choice?

That is, why someone might want to use gigantic fonts but constraint that
gigantic-ness to the actual letters, and not the indents too? Isn't it equally
important to see indentation clearly?

~~~
the_other
Why challenge someone's self-selected, battle-won access solutions before you
spend time with them understanding their choices?

~~~
prepend
For me the challenge is part of understanding choices. I don’t think of
challenge as conflict, but as a way of looking at different possibilities to
learn more about why.

~~~
afiori
There are many ways to pose a challenge.

> I don’t think of challenge as conflict

Agree, but I like to think of it as retrofixing your reasoning for the
different view: "You tell me A, but I used to believe B because of C, D, etc.
Can we investigate whether my reasoning was lacking, those are also in
conflict with A, A and B are not actually in conflict, or B has a validity not
influenced by A"

~~~
prepend
I like this symbolic way of putting it. I struggle with communicating that in
a way that is non-threatening to people who are sensitive or defensive of
their supporting beliefs E,F, etc for why A.

------
timonoko
M-X tabify had two benefits. Firstly it more than halved assembly source paper
tape. And secondly atleast Olivetti Teletype interpreted a TAB as a silent
jump, instead of 8 bang-bang-bangs of empty spaces.

------
_pmf_
That's the kind of practical real life inclusivity that I think should be
pushed instead of the "being offended by theoretical straw men" code of
conduct nonsense.

But I won't hold my breath.

------
ChrisSD
Surely version control solved this issue. Use whatever you like. Have a
standard for the repository itself. Auto-convert if and when necessary.

------
splodge
It's always fun pasting tab-indented code into the MySQL client...

~~~
Faaak
Then fix the mysql client...

------
colordrops
Most decent editors can operate with tabs or spaces functioning identically,
so this is mostly a moot point. With that in mind, spaces are easier to
display in tools that don't handle tabs well, so using spaces is still the
right approach in my estimation.

~~~
dkersten
And yet these visually impaired people apparently pleaded with the OP not to
take away their tabs.

Almost every program to edit text has a tab stop setting, but only the most
advanced dev tools allow you the same control over spaces. Anecdotally, I’ve
been struggling to get emacs to indent a certain language correctly for me (I
want it to use two spaces in a place where it only uses one, I’m not really an
emacs person so figuring out how to fix it is too much effort for me), if I
were to switch to tabs, that would be easy: just set the tab width and be done
with it. I don’t have any experience with screen readers, but it would seem to
me that they should have an easier time with tabs too.

~~~
prepend
I wish the story had described the editors used by the two visually impaired
coders. It seems odd that they are using an environment that doesn’t up/down
convert easily. It mentioned they were forced to do this like it was a manual
process.

Free IDEs like VScode do this, and it works with screen readers. Although from
the description of their screens with large fonts and wide resolutions, I
don’t think they were using screen readers.

Since the article is missing this bit, I can’t help that fear that all three
would have benefited from knowing how to config editors to get around this
problem.

~~~
scrollaway
No IDE I know of can reliably convert spaces to tabs in a display mode only (=
without actually causing code changes).

~~~
dkersten
Also, not every space necessarily should be converted to tabs, especially if
you follow the “tabs for indentation, spaces for alignment” mentality: you
will want everything up to the indentation level converted but not everything
after. I’m sure some editors can do this, but many also definitely can’t. Tabs
just work, everywhere.

------
feiss
I hope this is the seed to stop spaces nonsense..

------
master-litty
[redacting]

~~~
bhaak
Eyes don't get worse from use.

If you strain your eyes because of the lighting conditons, your eyes get
fatigued but it has no detrimental long time effects.

~~~
master-litty
Thank you, I seem to be severely misinformed. Redacting my original thoughts
now.

I have very poor vision and have been told by two different optomotrists that
for me, personally, my vision will worsen as I strain my eyes. I never thought
to wonder if this was different for anyone else -- One of those things it
seems.

------
syshum
There is no debate... every rational person knows tabs are better.

------
amai
Spaces are for people who understand addition. Tabs are for people who
understand multiplication. ;-)

------
vectorEQ
\t saves bytes compared to n*' '. there is literally no other reason to do
this. for 'style' both can be implemented to do the same and most editors
these days can replace one with the other and have configurable tabs, or 'use
spaces instead of tabs' options. in reality, if for example you sent a lot of
documents over the wire, or store a lot of documents on disk, using /t
compared to spaces can save a lot of bytes on disk or network... (looking at
the uncompressed case...)

