Hacker News Reader

Comment by mg | Hacker News Reader

In theory, tabs for indention and spaces for alignment would be the best way to handle whitespace.

Unfortunately in practice, two factors are in the way:

1) Most developers are confused by this type of whitespace usage. Simply because it is the less popular practice. So when you have a codebase that uses tabs for indention, you get more broken commits from developers who stumble in keeping the system intact.

2) Out of the box, VIM has no easy way to colorize tabs. So when you look at your code, tabs and spaces look the same. You cannot say from just if the whitespace is ok or messed up. You can show all non printing chars with "show list" but that is not very nice on the eyes. Or you can configure "show list" to only highlight tabs but then you lose the ability to show all non printing chars.

View on HN

> Out of the box, VIM has no easy way to colorize tabs.

This is slightly simplified from my .vimrc:

    highlight ExtraWhitespace ctermbg=darkred
    match ExtraWhitespace /\t/

It will highlight any tab in dark red.

(My actual .vimrc uses /\t\| \+$/ to also highlight extra spaces at the ends of lines.)

I hate (and am confused by) pretty much everything about vimscript, but this particular snippet is actually surprisingly clear.

Very nice! I hoped somebody might know an easy way like this when I mentioned it! HN for the win!

> Out of the box, VIM has no easy way to colorize tabs.

From my vimrc:

    set list
    listchars=tab:>-

It's not colorizing, but will list out a tab character as `>---`

Not exactly sure what you mean by "show list" but I believe you can append to `listchars` whatever nonprintable character formatting you want

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")

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?

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.

> 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.

Actually, in theory the best solution would be an IDE that handles whitespace sufficiently flexibly that the actual encoding of the whitesapce doesn't matter anymore. It has to reliably distinguish indentation whitespace from alignment whitespace. Then everyone could separately adjust the indentation to be N spaces in a codebase without needing to decide centrally on tabs/2spaces/4spaces etc.

Mixed is the worst. It doesn't make sense logically.

Isn't indentation just another kind of 'alignment'? After all, we use indentation to align text on the page... The differences between between all the supposedly distinct kinds of alignment are too subtle and difficult to describe in words to be used as a rule.

It's better to stick to simple rules that are easy to follow and enforce - Leave no room for ambiguous interpretations.

Also, I hate it when developers try to break up code in weird ways to align all the equal signs together for example. I would prefer that they never do this. Maybe if our eyeballs were stuck inside our heads in such a way we had to move our necks to read each letter, then it would be a good idea... Then it would be worth the complexity it adds. In the real world, however, moving one's eyeballs a few millimetres sideways isn't very difficult.

There is no need to litter your pristine code with extra spaces just to save people from having to shift their eyeballs a bit when reading your code. You save the reader like 10 eyeball shifts out of 1000...

> I hate it when developers try to break up code in weird ways to align all the equal signs together for example.

I do this in cases where I have many similar lines, for instance calling the same function many times with different arguments, and I want to make the differences between them more obvious. I find it to be much more maintainable and easier to read / identify bugs.

I would do the same, but it's unfortunately becoming more common for code formatting to be enforced with plugins, GitHub actions etc.

  start  = getData(  0,    0)
  middle = getData( 50,  -50)
  end    = getData(100, -100)

I would also exceed the line limit, if the arguments to only 1 of these lines are a bit longer. But apparently we now have to live with this:

  start = getData(0, 0, 0, 0)
  middle = getData(50000, -50000, 50000, -50000)
  end = getData(100000, -100000, 1000000,
    -100000)

(I have, completely accidentally, an extra zero in this. It would be easier to spot if it were aligned.)

This is a good example. I think the ideal way to support this would be an editor/IDE using tables for alignment. The compiler doesn't need to know about tables, whatever information the editor needs could be encoded entirely in a comment line preceding the table contents (which the editor would hide/replace with the table header unless the user chooses to reveal it).

Anyone using another editor would simply see a somewhat cryptic comment line followed by aligned code. And table-supporting editors could use a content hash to detect changes in the table contents and inform the user.

Elastic Tabstops is similar to what you propose, but using tab characters to form the tables: https://nickgravgaard.com/elastic-tabstops/#solution

But it's 15 years since that was proposed.

Similar, and I like the idea of Elastic Tabstops. A significant difference is that Elastic Tabstops won't look right in an editor that doesn't support them. What I'm suggesting would use spaces in the file and put metadata in a comment (though it could be stored elsewhere, too).

I find that the skill of reading code correctly without relying on visual aids can be trained and is a valuable skill. Visual aids won't help you to train this skill.

I'm confident that my ability to identify potential bugs quickly is correlated to my ability to visually spot tiny differences in the code. In both cases, you need to develop an extreme attention to detail.

It's one of those tradeoffs we make to save time. I get practice tracing program logic by reading poorly organized code written by others, but for my own purposes, I have a standard, consistent way of organizing/formatting things that saves a lot of mental overhead.

People make the same argument about static vs dynamic types -- "if you were a better programmer you wouldn't NEED to rely on type information!". Sure, I can juggle type information in my head just as well as anyone, but static types let me focus that mental effort somewhere else, and make context switching much easier.

What is language syntax but a visual aid that we all use to avoid writing assembly?

>> Sure, I can juggle type information in my head just as well as anyone, but static types let me focus that mental effort somewhere else, and make context switching much easier.

That is an extremely interesting argument. Personally, I find that overhead to be useful; the difficulty of keeping track of all the different types encourages me to design simpler interfaces between components. When I'm struggling with remembering what type some variable is, I know I've made the method interface too complicated (e.g. maybe the component should just keep the instance state internally and only accept an ID instead of a whole instance as argument). I guess that's why I prefer dynamic typing; it forces me to keep my interfaces simple and to think more carefully about state and logic co-location (to get high cohesion, loose coupling).

I like the Alan Kay quote about OOP "The Big Idea is Messaging". To understand this quote properly, we need to understand what "Messaging" means; it's about communication. Effective communication is about conveying intent; components should tell each other what needs to be done, not how to do it. Having complex interfaces which accept complex instances as arguments is akin to micro-managing the component. Typed languages are only particularly useful if you have complex interfaces. If you have simple method interfaces, you don't need a typed language because remembering what the parameters are for each method is trivial.

Reply on news.ycombinator.com