Hacker News Reader

Comment by runarberg | Hacker News Reader

I really don’t care about tabs vs. spaces anymore. I just go with what ever my auto formatter uses. But I do think we have been having the wrong argument all these years, and I think the proliferation of auto formatters are setting us straight, finally.

The issue is not tabs vs. spaces. It is block indentation vs. alignment. If you use alignment you are forced to use monospace fonts, if you use alignment with tabs, everyone is forced to set the same tab-stop (missing the point of tabs).

Block indentation on the other hand allows people to use whatever font they want (including non-monospace fonts) and what ever tab-stop they want. At that point it doesn’t matter anymore whether the indentation is done using tabs or spaces. The preferred font settings of the developers can deal with it.

View on HN

Exactly! Personally I find alignment (as opposed to block indentation) an annoying abuse of monospacing, especially when it's produced by overzealous code formatters.

> I just go with what ever my auto formatter uses.

Great on new code, but if you're doing this with older and messier codebases and not limiting the formatting to just your changes then you will ruin git/svn blame, at least places that don't ignore whitespace. If others are using the blame tool and frequently see your name then your coworkers might think less of you, even though it was just an auto formatter change.

If the team agrees with the formatting, I don't think anyone would "think less of you" for applying it.

> I just go with what ever my auto formatter uses.

Ah, so you're That Guy who messes up hundreds of irrelevant lines with whitespace changes along with their bug fix commit. :)

To be honest using non monospace font when coding should be be fireable offense.

I mean good luck with diffing that.

You right. Diff tools should use fixed width characters as diff operators (em-space, minus-sign, and plus sign are usually the same width in most fonts), but I doubt any diff tool does. It is a shame. The only reason we use monospace fonts as an industry is because that is how we’ve always done it, and now we are stuck there because we fail to think out side of the box (pun intended) when we make our tools.

Not just diff tools. When you write your own code you are constantly diffing against other code. In essence monospace font prevents these kind of small errors.

Monospaced fonts are good for editing. Variable width characters are good for quick reading because they allow you to scan past spelling errors in prose. Monospaced fonts have distinctive 'textures' that make them amenable to detecting symbol identity. Variable width fonts intentionally eliminate that texture and are often optimized for ink density to 'grey out' blocks of text. Arrow keys don't work predictably in variable width text.

There is no reason font designers can’t create variable width font faces that optimize character distinctions and important features while reading code. Many font faces even have settings that allow you to opt into making characters more distinguishable.

You are right about navigating between lines in a variable width fonts. However that is a problem with many text boxes on the web (including slack and github) and I don’t find it that much of a headache. I find it kind of rare that I need to navigate between subsequent lines and maintain the column except maybe at the start of the indentation level.

> To be honest using non monospace font when coding should be be fireable offense.

Unless I'm coding with a wordprocessor that embeds my font choices and forces them on others, why should anyone else care, much less have cause to punish?

> I mean good luck with diffing that.

“Diffing” and “coding” are different code-related activity and aren't constrained to use the same font, so why would my choice of coding font have any effect on diffing?

Merely downvoting your comment should be punishable by a six month revocation of internet access.

Reply on news.ycombinator.com