Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Tabs vs. Spaces war is over, and spaces have emerged victorious

xn--gckvb8fzb.com

Post reply on HN
Print view View original

61–70 of 238 posts

Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious

#61

Post by thih9 »

Izkata wrote: post #53
thih9 wrote: post #46

Earlier quoted context omitted.

> You can use tabs to indent and spaces to align after that, in most cases. In practice this is difficult; since the characters are invisible by default, people will inevitably mix up the two. Looks like the industry standard is to give up and use spaces everywhere, unless strict and mandatory tooling exists.

And that was (one of the reasons) why spaces won: alignment always worked. But the new problem is linters and formatters don't understand alignment, so they always want those extra spaces removed, making a mess.

> linters and formatters don't understand alignment, so they always want those extra spaces removed, making a mess.

I’m not sure what are you referring to, could you give an example?

Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious

#62

Post by JohnFen »

quietbritishjim wrote: post #54
mjburgess wrote: post #2

The point of the "tab" option is that there is no consensus on the number of spaces to use -- so by using tab, one uses a single character, and allows the developer to determine screen spacing to their comfort. "Tab" being a live option is a symptom of the war-never-over in absolute spacing degree -- since different people have different eye-sight, eye-strain, etc. constraints, different linguistic familiarities, cod…

> so by using tab, one ... allows the developer to determine screen spacing to their comfort (Allow me to reply to this age-old argument with the age-old counter argument...) But you also have to decide at what point to hard wrap each line based on a max line length, and you can only do that based on some choice of tab size. Anyone with a different tab size preference would see the right column wandering depending on…

> But you also have to decide at what point to hard wrap each line based on a max line length

I think that you should not be doing this, for the same reason that you should use tabs. It allows the user to select whichever hard wrap point (if any -- I generally choose to not have one) they prefer.

But all of this sort of thing is pointless debate these days, when it's pretty fast and easy to preprocess the files to match your preferences prior to editing.

Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious

#63

Post by purpleidea »

Tabs are the preferred, more efficient and more accessible format, and most people know this. Every golang dev loves just having one tap to indent code, and nobody loves the constant repeat rattle of space indented code.

Seriously though, tabs let you pick what's visually easier for you to read and I've worked with coworkers that struggle when indentation isn't clear.

Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious

#64

Post by moomin »

mjburgess wrote: post #2

The point of the "tab" option is that there is no consensus on the number of spaces to use -- so by using tab, one uses a single character, and allows the developer to determine screen spacing to their comfort. "Tab" being a live option is a symptom of the war-never-over in absolute spacing degree -- since different people have different eye-sight, eye-strain, etc. constraints, different linguistic familiarities, cod…

I’d say that one’s approaching resolution, too. And 4 has won.

Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious

#66

Post by deafpolygon »

I've always been team Tab. I prefer tabs, even in my CSV (actually, TSV) files. But everyone else has decided this for me and I have begrudgingly adopted spaces. Even though Tabs can be set to whatever anyone wants at no switching cost to anyone else. Imagine if Python used actual Tabs.

Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious

#67

Post by xipix »

throwawayqqq11 wrote: post #31
jihadjihad wrote: post #4

Rob Pike on why Go is indented with tabs [0]: > How wide should the indentation be? 2 spaces? 4? 8? Something else? > By making the indent be a tab, you get to decide the answer to that question and everyone will see code indented as wide (or not) as they prefer. > In short, this is what the tab character is for. 0: https://groups.google.com/g/golang-nuts/c/iHGLTFalb54/m/zqMo...

Exactly. Indentation != spacing. And thats all the argument i need. I dont understand why people argue with consistent text layout for all-spaces. You can use tabs to indent and spaces to align after that, in most cases.

You can't use spaces to align because you can't assume a monospaced font will always be used. You can't use tabs either for that matter. If you need structure, use the language's punctuation and line breaks.

Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious

#68

Post by IncreasePosts »

phplovesong wrote: post #3

Tabs are better, simply because you can view them as you like. Go obviously does this, and Haxe too (with default formatting options, even tho its configurable)

It seems problematic to have a single character in the entire universe for characters render as variable, user controlled width.

Re: The Tabs vs. Spaces war is over, and spaces have emerged victorious

#69

Post by jedberg »

PaulDavisThe1st wrote: post #52
jedberg wrote: post #23

Earlier quoted context omitted.

Spaces are better, simply because you don't have to worry if another developer is seeing the code different than you. See, I can do it too. This is why there is an ongoing discussion. Because there is no clear cut answer, just opinions. At least this article brings some data to the discussion.

> another developer is seeing the code different than you. but that's the whole damn point ... I like substantively indented code, you prefer minimally indented, we should both be happy (and we can be, by using tabs).

You could certainly make that argument. You could also make the argument that all the developers on a project seeing the same view of the code enhances collaboration and team cohesion, especially if your team does pair programming.

This is often why dev teams have more specific style guides that include things would be considered bike-shedding, like how many spaces an indent is.

Post reply on HN