Nobody talks about the real reason to use Tabs over Spaces

We discussed this 5 days ago:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20341354" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20341354</a>

Been saying for years that tabs are an accessibility feature. It&#x27;s good to see a thread get some traction. I&#x27;ve never understood why people -- logical people; programmers -- are so religious about spaces, especially in the Python community.<p>A while back I tried to make the case to the author of Black (The python community&#x27;s excellent auto-formatter) to add a &quot;--use-tabs&quot; option. I was not successful; I had to fork Black to be able to use it. <a href="https:&#x2F;&#x2F;github.com&#x2F;jleclanche&#x2F;tan" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jleclanche&#x2F;tan</a>

The reason it&#x27;s more accessible is because it&#x27;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 <i>semantic</i> property, not a visual one.

I&#x27;ve been a tab user since forever. The biggest issue with using spaces is not how much you indent, it&#x27;s the bad pattern of aligning stuff vertically beyond a simple N-level indent.<p>Using spaces to align stuff on multiple lines causes multiple problems.<p>Any changes will affect surrounding lines. This adds busy-work to realign everything, especially if you&#x27;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&#x2F;rebase conflicts.<p>It&#x27;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.

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

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?<p>And then the world duly standardized on 4-spaces-per-indent.<p>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.

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

I do not really care for tabs vs spaces, <i>except</i> 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.<p>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.

I cannot suggest enough to avoid this debate and pass to elastic tabstops<p><a href="http:&#x2F;&#x2F;nickgravgaard.com&#x2F;elastic-tabstops&#x2F;" rel="nofollow">http:&#x2F;&#x2F;nickgravgaard.com&#x2F;elastic-tabstops&#x2F;</a>

<i>these guys have serious problems using codebases with spaces, they have to convert, do their work, and then unconvert before committing</i><p>I used to work for a company that had automatic formatting on checkin&#x2F;checkout --- everyone had his&#x2F;her own formatting preferences (tabs&#x2F;spaces and how many was one of them), which deviated slightly from the &quot;official&quot; one, but the process was basically completely automatic.<p>My personal preference is <i>one</i> space --- files are just as small as with tabs, and the column counter of the editor also directly corresponds to the indent level.<p>Also, the lack of capitalisation and run-on sentences in a post arguing about accessibility is a bit ironic.

Use tabs for indentation, space for alignment, why do it anyway else?<p>I especially like Linus Torvalds view on indentation:<p><i>&quot;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.<p>Rationale: The whole idea behind indentation is to clearly define where a block of control starts and ends. Especially when you&#x27;ve been looking at your screen for 20 straight hours, you&#x27;ll find it a lot easier to see how the indentation works if you have large indentations.<p>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&#x27;re screwed anyway, and should fix your program.&quot;</i><p><a href="https:&#x2F;&#x2F;github.com&#x2F;torvalds&#x2F;linux&#x2F;blob&#x2F;master&#x2F;Documentation&#x2F;process&#x2F;coding-style.rst" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;torvalds&#x2F;linux&#x2F;blob&#x2F;master&#x2F;Documentation&#x2F;...</a>

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&#x27;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).<p>As a side note: I wish that JavaScript had a utility like the &quot;indent&quot; utility in Unix for precisely styling C code. Prettier is close; however, it cannot be customized in the detail that I would like.

This is a decent argument but calling it &quot;the real reason&quot; takes away from it.

Yes, it&#x27;s pretty obvious that Tab is correct since it has semantic meaning (tab = indent), is one character and has configurable width.

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&#x27;s preferences.

I totally agree, as a dyslexic big pieces of text look like a garbled mess. I need &gt; 2 spaces to be able to navigate a file with code with any speed.<p>Tabs for indentation, spaces for alignment looks to me like the best of both worlds.

I generally don&#x27;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.<p>That aside, I don&#x27;t feel that this particular argument any stronger than any personal preference, let alone some kind of be-all final reason.<p>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.<p>The post author calls for more editors to support adjusting tab widths showing that using tabs isn&#x27;t automatically an accessibility win - spaces users could just as easily call for more editors to support custom ligatures to help the visually impaired.

Despite adding a valid perspective, this is mostly clickbait.<p>A file is just a storage format. The real issue is that IDE&#x27;s don&#x27;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 &quot;get everybody on the same page&quot; and in the process create winners and losers.<p>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.

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&#x27;ll be sure to ask whether tabs would be useful to the team. I&#x27;m a big believer that Team-level consistency is far more important than Universe-level consistency, and silver bullets kill.<p>That said, I&#x27;m intrigued - surely this must be a solved problem at this point? Anybody aware of any good text editors &#x2F; editor plugins that allow you to modify the visual spacing of start-of-line spaces?

An excellent argument. I&#x27;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&#x27;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.<p>But in light of this argument, yes, lets move to tabs instead. More control for the user in how you actually display them.

Nobody talks about the fact that git can convert tabs to spaces and vice-versa on the fly so the whole discussion is irrelevant :-)<p><a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;a&#x2F;2316728" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;a&#x2F;2316728</a>

&gt;<i>one of them uses tab-width 1 because he uses such a gigantic font-size</i><p>But if they use a &quot;giganting font-size&quot; 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?<p>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&#x27;t it equally important to see indentation clearly?

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.

That&#x27;s the kind of practical real life inclusivity that I think should be pushed instead of the &quot;being offended by theoretical straw men&quot; code of conduct nonsense.<p>But I won&#x27;t hold my breath.

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

It&#x27;s always fun pasting tab-indented code into the MySQL client...

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&#x27;t handle tabs well, so using spaces is still the right approach in my estimation.

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

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.<p>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.<p>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.

[redacting]

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

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

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