The only true answer to 'tabs vs. spaces' | Hacker News Reader

The only true answer to 'tabs vs. spaces'

garrit.xyz

10 points8b16380d34 comments

As someone who was a die-hard tabs guy for ~30 years, but has been using spaces for the last ~10: This post is correct, but irrelevant.

I hung onto tabs for the reasons mentioned in the article: It doesn't require agreement on the number of spaces for an indent. I always liked 3 (a bit bigger indent than 2, not so much space as 4), but tabs meant people could pick whatever they liked. A single character that means "another indentation level" makes a lot of sense to me.

But, at least in the Python world, spaces have won. So I switched, and whatever.

I have bigger fish to fry, I'll use whatever. If I was on a team that chose tabs, I'd be fine with it. But I'd also be fine with spaces. Life is too short to care, tooling largely just takes care of it.

> Life is too short to care, tooling largely just takes care of it.

What's the point of even existing if you can't argue over minutia?

Yeah, I'm surprised this is even still discussed. Most editors have a setting so I just adapt to what the code I work on is using and most often I don't even notice if it's spaces or tabs. I haven't seen anyone manually typing four spaces anyway. (At least not in the last decade or so.)

There is one really good reason to always use tabs: accessibility.

This comment is what sold me https://github.com/prettier/prettier/issues/7475#issuecommen...

I've seen this -- I'd be interested to know how many blind coders are using braille displays. I only know two blind coders, but both use standard accessible editors, using text-to-speech. They don't care about tabs vs spaces. I'm not sure which editors work well with braille displays (if any).

They do care greatly about sticking 100% to an auto-code formatter, not for their benefit of reading other's codes, but so they didn't need to worry about accurate formatting themselves, which is another excellent reason to just pick a code formatter and use it on every commit religiously.

Yes! Not just braille, but eyesight problems in general. Someone using a 100pt+ font so they can see code really don’t want masses of screen estate used by spaces.

That comment wins. I have used spaces for decades and this is the most compelling reason I've seen to change that. Sold.

I think there's another, equally-good answer:

"I don't care, as long as it is consistent per codebase."

I work on a codebase that my team owns, and we use spaces. I work on another codebase another team owns, and it uses tabs. I use whatever the codebase wants.

Your answer isn't equally-good, it's worse. The argument for tabs is that each user can set them to display however they'd like. That's obviously not possible with spaces. So tabs make more sense.

Why isn't it possible with spaces?

If an application is capable of rendering a tab as say N px of white space why can't it render 2 spaces as N px of white space?

It is possible and there's IDE extensions for this at minimum for VSCode, it's just impossible to be consistent with tab indents, because you'll inevitably have to align with a space.

> it's just impossible to be consistent with tab indents, because you'll inevitably have to align with a space.

That's definitely application specific. I've seen other applications (not IDEs) use variable width tabs so that tabular data (Tables) would line up very well with only a single tab.

Because if someone sends me 8 space code and I'm normally 2 space code rendered as 4 spaces...

And if they send you a 8 tab'd code and you normally only use 2 tab's then you'd have an issue as well.

Then your editor renders the 8 space code as 4 spaces without missing a beat. Why wouldn't it? Detecting the indentation level used is trivial. (Provided, of course, that the author had the foresight to use spaces, not tabs.)

>Detecting the indentation level used is trivial.

I agree that parsing a known correct file is trivial. Wouldn't a trivial thing be solved by now?

Whenever I open a C file in Emacs, the indentation level is autodetected. I'll admit that may not have been trivial to implement, but it certainly has been done.

More importantly, some people can only see maybe a dozen characters at a time due to vision impairment.

To me, "can someone without good vision work with this code" was all the argument needed. Preferences, sure, accessibility though? Why not just make it simple?

Rust also disappointed me on this, I just have never heard an argument for spaces that comes close to functional rather than just aesthetic. I don't honestly know why this is such a controversial topic.

I was initially angry at the decision to use tabs instead of spaces in gofmt, but the advantages of having 95% of go projects use the exact same formatting has won me over. I'll happily give up my habits and preferences for more universal consistency.

I love that an article that can basically be summarized as: “tabs or spaces? - tabs” is on the front page of hacker news

I think the arguments in favour of tabs are pretty strong. But there are a couple of small issue:

- You can't have aligned tables of data / blocks of comments / etc. if group of lines containing the aligned text have different amounts of indentation.

- You can't place a fixed limit on line width (which many code formatting standards do, presumably to reduce horizontal scrolling and facilitate side-by-side diffs).

A lot of tools exist to autoformat code to a standard, or the language has one. Use the tools. In C++ we have clang-format, set it up and leave the decision to that. It just saves so much hasle and takes emphasis off of something that doesn’t matter by making it not matter.

Be nice to have a language that's designed to be formatted on the fly by the editor.

Brings up my point, people need stop designing languages based on parsing raw text.

That doesn't really make sense in the world of people typing their programs. It is text.

Tabstops are still 9, 17, and every 8 thereafter... the standard on the VT-52 and VT-100 is still used when you 'cat' a file, and if you write files with tabs otherwise, you will have trouble with the console and the printer. Which is to say, I'm still fine with a tabs substituted for spaces wherever you like.

The true answer is "Whatever comes out the other side of your `format' command."

And if you don't much care for what format outputs, configure your IDE to display it however you want it to.

Douglas Crockford favours spaces in this great talk https://youtu.be/En8Ubs2k1O8

Show me a single project where the decision either way has made any difference to the outcome. Stop wasting time discussing it.

It's when the decision is "whatever I want" where the demons await...

Didn't Stephen McConnell settle this in the 90s in Code Complete? Spaces, no fewer than 2 and no more than 4, and follow the main convention of the language.

Granted, you're hosed if you wrote C for the Linux kernel; you were stuck with 8.

Well I sure am glad we settled that.

Bookmarking this story so I never forget this used to be a point of contention.

tabs vs spaces boils down to concern for others

using tabs means everyone else can view the file with as many spaces as they want

using spaces forces everyone else to view the file exactly as you see it

are you trying to start a civil war?

Reply on news.ycombinator.com