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

151–160 of 238 posts

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

#151

Post by throw-the-towel »

PaulDavisThe1st wrote: post #44
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.

the correct rule is: tabs to indent, spaces to align [TAB][TAB][TAB]ShortTypename[SPACE][SPACE]variable_name [TAB][TAB][TAB]LongLongLongTypename[SPACE]variable_name2 ps. the [SPACE] counts above are illustrative, not accurate.

The correct rule is: you shouldn't align.

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

#152

Post by g-b-r »

PaulDavisThe1st wrote: post #45
jl6 wrote: post #40

Tabs are the modern choice, because you can then configure your editor so that for every tab character, it calls an LLM with the buffer contents up to that point, with instructions to generate an appropriate number of spaces that can then be substituted in. You might be thinking 2, 4, or 8, but the LLM will give you the contextually-correct answer.

LLM? Emacs has been doing this for decades without any such technology.

Emacs can let a butterfly flap her wing, causing momentary pockets of higher-pressure air to form, which act as lenses that deflect incoming cosmic rays, focusing them to strike the LLM's memory; the LLM will then report the appropriate amount of spaces.

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

#153

Post by kevin_thibedeau »

arccy wrote: post #140
kevin_thibedeau wrote: post #59

Earlier quoted context omitted.

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

but the autoformatter will have dictated the choice of space vs tabs for the file in question, an likely also the width of tabs (if any) for alignment. so you just need to follow the convention.

The whole point of preferring tabs is so you can customize the display. That can't work if tabs are used in fixed format text.

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

#154

Post by SAI_Peregrinus »

em-bee wrote: post #127
SAI_Peregrinus wrote: post #92

Earlier quoted context omitted.

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.

which editor does that? space width is defined by the font, and normally you use monospace fonts. i am unfamiliar with any editor that allows you to choose a different font for spaces. besides, it would only work for indents, it would mess up any alignment of code into columns.

None, but it's clearly possible to add since such handling is already present for tabs in almost any editor. I merely mean that there's no technical restriction.

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

#155

Post by SAI_Peregrinus »

eikenberry wrote: post #98
SAI_Peregrinus wrote: post #92

Earlier quoted context omitted.

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.

But don't fixed width fonts, which many consider the best for code, mean fixed width spaces too?

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.

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

#156

Post by g-b-r »

dusted wrote: post #144

It's slightly insane that computer programs are still mostly derived from plaintext files.. but what's absolutely insane is that we, the people creating those programs, do so by modifying individual characters in those very same plaintext files.. Yes, text is a good interface medium for exchanging program descriptions between humans and machines.. but it's not a very good medium for storing and exchanging program des…

> variable naming and so on.. all stuff that's there for the humans, the compiler don't care what you name your variables.. It's insane that there's no abstraction here..

You would have variable names not saved? They don't matter for the future maintenance of the program?

You can have most of what you ask right now, the further step most relevant here would be to not indent anything in the saved code; with most languages you're free to do it, and it's feasible to have an editor display it with the indentation you prefer; however it could only make sense if there's no way to have your team agree on an indentation style, there's too many fldownsides with hardly any advantage otherwise.

You're always free to have your editor ignore the spaces and display the code the way you prefer, anyhow.

But it's probably not always possible to deduce how things should be aligned.

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

#157

Post by hollerith »

throw-the-towel wrote: post #151
PaulDavisThe1st wrote: post #44

Earlier quoted context omitted.

the correct rule is: tabs to indent, spaces to align [TAB][TAB][TAB]ShortTypename[SPACE][SPACE]variable_name [TAB][TAB][TAB]LongLongLongTypename[SPACE]variable_name2 ps. the [SPACE] counts above are illustrative, not accurate.

The correct rule is: you shouldn't align.

The code I maintain (Emacs Lisp) follows that rule.

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

#159

Post by g-b-r »

ytpete wrote: post #111
camel-cdr wrote: post #55

Earlier quoted context omitted.

Disallowing /[^\t]\t/ and /^ / is a good start.

These regexes don't solve what I think is one of the major common problems/complaints though: using extra tabs past the logical indent point as a shortcut to avoid typing so many spaces for alignment purposes. To take this example from a sibling post: if (foo) { » frobnicate(bar, » ...........baz); } Many people will wind up doing this: if (foo) { » frobnicate(bar, » » » ...baz); } And then your alignment is all mess…

At some point you just have to flog people ;)

Anyhow, if code reviewers always use tools that highlight the tabs during the reviews, there's a good chance to catch these things.

Maybe you could also have the tab width set randomly at every review, to make these horrors stand out

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

#160

Post by g-b-r »

jahewson wrote: post #99
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

Actually for me this shows why tabs don’t deliver on their promise. As soon as the user’s tab size is small enough that baz doesn’t need to wrap, the user gets suboptimal formatting. As someone who prefers tabs of 2 and often views code authored with tabs of 4 I encounter this often.

Your team should settle on a maximum line length independent of which tab settings one has

Of course that will always be a compromise, either people who use narrow tab widths or those who use wide ones will have a (slightly) suboptimal experience.

Post reply on HN