Hacker News Reader

Comment by samatman | Hacker News Reader

Don't agree, here's why:

    -- this comment is on the margin, the code is indented
          youCantDo("this kind of",
                    "function parameter",
                    "mixing tabs and spaces")

View on HN

I don't get why people do that. It's ugly, and it breaks when the `youCantDo` name changes.

        youCanDo(
            "this kind of",
            "function parameter",
            "with just tabs"
        )

Ugly is subjective.

Vertical space is at a premium, and 'wasting' five lines when three will do strikes me as uglier than the opposite. Adjusting spaces when things get refactored doesn't strike me as especially tedious, but YMMV.

I don't go so far as to support "lisp style" closing braces for brace-block languages, though. It's just too weird.

Agree that ugly is subjective. But adjusting spaces when things get refactored is bad, not because it's tedious but because it pollutes history. Changing whitespace on surrounding lines to my change makes eg `git blame` less informative. It's the same reason I believe in trailing commas.

I acknowledge this problem while throwing up my hands at the incredible laziness of the entire profession in not employing syntactically-aware diffing.

It's our own fault, we have no excuse, and it galls me to serve a dumb line-based algorithm over the writers and readers of my code.

Ideally, what is stored in version control is just the AST, and how you or I display it is up to our own preference. Then I won't have to care about your weird indentation preferences and other style choices and you won't have to care about mine!

Agreed fully, these are my reasons too, and I'm quite sorry for not having included a trailing comma in my example :)

But it does make for more compact and easier to read diffs.

Don't agree, here's why:

    -- this comment is on the margin, the code is indented
          youCantDo("this kind of",
                "function parameter",
                "mixing tabs and spaces")

No idea what you tried to do here, but this doesn't line up properly.

Fix it and I'll merge: except I wouldn't see it because CI won't pass code with tabs in it.

Yes, you can.

The three lines of code all start with exactly one tab. The second two lines each have 10 spaces after their initial tab.

But which editor has support for that?

I don't think even emacs has good support otb for mixed tabs like that. The typical behavior is to convert all spaces at beginning of line that are multiples of tab-width to tabs.

I've been doing it for ~10 years in vim without a single issue.

Great so I'm using two kinds of invisible character in a pointlessly difficult way... why, exactly?

Can you write a linter for this which doesn't contain a complete parser for your language?

> invisible character

Which respectable text editor in 2021 doesn't have an option to show whitespace?

> Can you write a linter for this

Every linter uses a "complete parser", else it wouldn't be a linter.

I'm not in favor of the solution I posted. I only shared it because it is a solution to the problem that was presented.

Reply on news.ycombinator.com