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

191–200 of 238 posts

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

#191

Post by RGBCube »

ben-schaaf wrote: post #164
tinco wrote: post #80

Earlier quoted context omitted.

No one who uses tabs would ever assume a certain tab width for visual alignment. What do you base that slanderous statement on? I've also never heard anyone argue that someone else should configure some different tab width, is there a specific language ecosystem you were in that had these insane takes?

To quote the linux kernel style guide: > Tabs are 8 characters, and thus indentations are also 8 characters. Yes, tabs are used for alignment as well. To quote the OpenBSD style guide: > Indentation is an 8 character tab. The GTK source code uses tabs when the number of spaces for indentation >=8. This goes against their coding-style document, but if you don't have tabs set to 8 you'll find the indentation broken. gi…

This is horrible and goes against the purpose of tabs. You should NEVER use tabs for alignment, only for indentation.

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

#192

Post by RGBCube »

GeorgeTirebiter wrote: post #30

Completely agree: tabs FTW. I wish I could find the reference, but when dealing with mono-spaced fonts, readability is apparently enhanced with THREE spaces per indent. Now, good computer people hate non powers-of-two, so it's either 1, 2, 4, or 8 spaces!!!! I guess I'm not a good computer person, because my eyes find tab stops at '3 spaces per tab' just right.

I also use 3 spaces myself, because 4 spaces is too damn wide and 2 spaces is a little bit too small. I would use tabs instead, but rustfmt doesn't handle it well at all in some of the nightly options, I've had it use spaces where it should use tabs a lot.

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

#193

Post by 112233 »

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.

Not to mention that space is a normal printable character, while tab is a control character, like carriage return. Control characters have very well defined meaning, that is very different in different contexts.

As an example, and I hope this is not a new information for most, in many text terminals it does not mean "advance forward to a multiple-of-8 position", it means "advance forward to next tab stop", and you can arbitrarily set those (e.g. HTS/TSC on vt220)

If tabs or spaces are mandated at editor level, how are you editing Makefile or TSV files?

I really do not understand anyone, who is against having support for any possible indentation, controlled by the user as is necessary for each use case.

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

#195

Post by citrin_ru »

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

Exact and strictly enforced max line length IMHO unnecessary. Too wide code is hard to read, too narrow too but in between there is a wide range of acceptable values. When possible I treat max length as a recommendation, not hard limit.

When you don’t have a hard limit it’s not a problem if code added by someone who uses visual tab width 2 will go over 78 characters in the editor which tab width set to 4. Equally it’s not a problem when someone using 4 will make a line break sooner than one using 2.

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

#196

Post by sokoloff »

jahewson wrote: post #173
sokoloff wrote: post #146

Earlier quoted context omitted.

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.

Eh. If 1 line of code in 500 has a trailing bit of punctuation scrolled off the side for 1 in 8 coders who have chosen to have both narrow windows and wide tabs, that hardly seems like a deal-breaker, but if it is, enforce common settings/standards.

(I'm fully converted to Team Spaces, but I also don't get too wrapped up in treating what seem to be soft limits as hard limits.)

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

#197

Post by conartist6 »

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 war is ending though.

It will be over when we finally format code at read-time so that we respect the viewer's preferences, instead of at save-time to reflect the authors'.

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

#198

Post by frizlab »

DrSiemer wrote: post #185
frizlab wrote: post #148

Earlier quoted context omitted.

I know the shortcuts. (It’s not ctrl-arrows; ctrl-arrows is to switch Space.) There are still situations where it’s annoying, mostly when navigating the code using the arrow, moving from one location to another using the arrows, I won’t add a key modifier right in the middle of moving the cursor, it just doesn't make sense.

Switch space? On any Windows OS ctrl-arrows (left and right) move the cursor by word. I don't exactly understand how people work with code or even do text editing without it.

I’m on macOS and it’s alt-space.

Ctrl-space moves the cursor by “words inside words,” e.g. in theBestVariable, will go between “the” and “Best.” However it conflicts with the system ctrl-space that switch space. Not really an issue, because ctrl-shift-arrow will do the same word inside word move, but extending selection. In the end we can select until the desired location is reached, then hit a single left or right arrow to deselect and we’re there.

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

#199

Post by jononor »

eikenberry wrote: post #161
SAI_Peregrinus wrote: post #155

Earlier quoted context omitted.

If that were the case tabs would be fixed width too. But they're not. There's no fundamental reason tabs have to be the only variable-width character.

Tabs would only be variable in the number of spaces uses, but those spaces will be fixed width.

And spaces could be variable in the number of "sub-spaces" used. Each could be say 1/8 of a regular space.

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

#200

Post by mananaysiempre »

phplovesong wrote: post #186
mananaysiempre wrote: post #20

Earlier quoted context omitted.

That’s mostly editor braindamage (that has unfortunately leaked into some otherwise very good codebases, like LuaJIT). Indent things with tabs, align with spaces[1]: if (foo) { » frobnicate(bar, » ...........baz); } Both camps will hate you, but things will work just as they should. [1] https://www.emacswiki.org/emacs/SmartTabs

Formatting by hand is probably only going to work for private hobby projects. In 99% of the other cases there needs to be a formatter that does the formatting.

That feels both largely irrelevant and false? False, because there are plenty of large projects that do have a house style but don’t use a formatter at code submission to enforce it—even if you reject the Linux kernel as an atypical example, basically every piece of commercial software from 20 years ago also fits, simoly because both formatters and presubmit checks weren’t nearly as common, and there were some chonkers there (like, I don’t know, Windows XP). Irrelevant, because it’s perfectly possible for a formatter to follow this convention (gofmt does, for example).
Post reply on HN