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

171–180 of 238 posts

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

#171

Post by birn559 »

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…

The problem with this is: 1. It's relatively hard to think it through to the point that you see and have the potential benefits in all cases(*). 2. All participants and tools must fully support the solution. It needs a momentum it never got so the world settled on a simpler solution.

(*) Tabs only and no hard wraps, only soft wraps.

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

#172

Post by Jensson »

1718627440 wrote: post #115
PlunderBunny wrote: post #108

Earlier quoted context omitted.

The VAX/VMS terminals we used at university to learn Pascal defaulted to 8 space tabs, on a 80 column screen. That certainly pushed some people towards using spaces.

I use 8-sized tabs with 72 columns in C. The human eye doesn't like moving all that much while reading and more windows fit one the screen even if it is annotated with git blame. In addition there is this argument from Torvalds, that you should mind your maximum nesting in a single function, which I also find useful.

> In addition there is this argument from Torvalds, that you should mind your maximum nesting in a single function, which I also find useful.

Note that nesting is a much bigger issue in a language like C where you have to clean up after yourself, in most languages having a lot of nesting in a function isn't an issue.

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

#173

Post by jahewson »

sokoloff wrote: post #146
jahewson wrote: post #107

Earlier quoted context omitted.

Wait, no, if there is an 80 character line limit and you like 4 space tabs but I like 2 space tabs, we’re going to have a problem. My code will exceed the line length on your screen or be forced to wrap prematurely on my screen to suit your preferences.

I'm not at all convinced that an 80 character line limit makes sense on modern equipment. On punch cards, teletypes, or VGA CRTs? Absolutely. On SVGA CRTs? Probably. On anything modern? No.

Personally I use a 100 character limit. Anything more and the ability to have two editor windows side by side gets impeded upon. The point is, there is a limit.

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

#174

Post by eviks »

SAI_Peregrinus wrote: post #92
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…

But an editor can just as well let the user choose what width to display spaces at the start of a line. Nothing forces them to be the same width as spaces in the middle of a line.

Nope, an editor can do that, but it can’t do it just as well because not all spaces at the beginning are indentation, so then you need to have more complicated rules to differentiate between those cases

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

#175

Post by eviks »

o11c wrote: post #16
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…

There absolutely is a consensus: a hard tab is defined as 8 spaces in numerous standards (obviously this only applies to monospace fonts). The fact that people choose to reject this does not change the reality.

Reality is what people use. Consensus is what almost all people agree on. Standard is just some rule a few people thought would be good to follow.

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

#176

Post by eviks »

xipix wrote: post #67
throwawayqqq11 wrote: post #31

Earlier quoted context omitted.

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.

You can use tabs, that’s exactly their role, but only in theory since in practice elastic tab stops that would work with proportional fonts aren’t implemented anywhere in code, only word processors

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

#177

Post by justinclift »

kevin_thibedeau wrote: post #59
bbkane wrote: post #29

The most important thing is consistency. I've become a huge fan of deferring tabs vs. spaces debates to an autoformatter. Set it; forget it; argue about something else. This is most useful when applied ecosystem wide - no one in the Go ecosystem argues about tabs vs spaces, they just run `go fmt` (or more likely their editor is set to do that automatically) and move the #$@% on with life :) Fortunately for me, newer…

An autoformatter wont touch a tabbed ASCII diagram in the comments,

Go's autoformatter will absolutely screw up existing ascii comments when they randomly decide to change how the formatting works.

As found the hard way when one day we updated the version of the Go formatter, and much of our nice comments needed to be redone. Thanks Go formatter team (yes, that's being sarcastic).

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

#178

Post by [deleted] »

pabs3 wrote: post #165
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…

The right number of spaces to use is one.

[deleted]

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

#179

Post by lioeters »

chrisweekly wrote: post #25

The choice isn't (tabs) vs (spaces). It's (tabs && spaces) vs (spaces). In the real world, there will always be spaces, whether used for indentation or not. Using tabs for indentation inevitably leads to a mix of both - which is, objectively, worse for maintenance and consistency.

I'm amazed that your comment is the single reasonable take among this entire discussion full of unsupported assertions and opinions.

Having two different invisible characters to represent empty space is objectively worse. Just use space, and the tab key to insert multiple spaces. Simple. Use .editorconfig and a formatter to enforce the commonly accepted standard. Done.

Sadly you still have to make exceptions for Makefile, Go, etc. that expect a mixture of hard tabs and spaces. Otherwise hard tabs are not allowed in the codebases I manage, and are replaced by the formatter.

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

#180

Post by wodenokoto »

When I started programming in Python I was all like “why do they even allow tabs?” But now I’m like “why did they ever allow spaces?” Space indentation is only nice if your editor has all sorts of weird logic to handle spaces at the beginning of a line as though they where half or a quarter as many tabs.

Just use tabs!

Post reply on HN