Comment by dTal | Hacker News Reader

Comment by dTal | Hacker News Reader

Parent Full thread

My impression is that many people are not confident in their understanding of tab behavior; there's a perception of them being weird, unpredictable voodoo (as exemplified by comments which imply that many programs don't support tabs well, despite that virtually all programs support tabs flawlessly, right down to notepad and standard GUI toolkit textboxes.)

I think this stems from a broken mental model, whereby tabs are regarded as "representing x number of spaces", where x is some unknown variable in the editor of whoever created the file. These people say things like "tabs are just a compression mechanism" and "tabs are inconsistent across editors". In the minds of these people, spaces have primacy, and tabs are just weird inconsistent not-spaces that catch you out.

The proper mental model, of course, is to recognize that tabs don't represent any number of spaces - they represent indents, and that's that. You could quite happily set your editor to display tabs as indents π spaces wide. It is an error on the part of the person writing the file to assume any particular tab width.

There are a few coding style conventions that break the assumption that the indentation should strictly reflect the nesting depth, like breaking up a long argument list over multiple lines and trying to line the second line up with the opening parentheses. In my view these are bad coding styles anyway and should be retired.

> You could quite happily set your editor to display tabs as indents π spaces wide.

There was a viral joke tweet a while back suggesting that successive indents should be displayed with ever-increasing widths following the Fibonacci series. The result looked quite nice, actually!

The issue with tabs as indent level is that there are two reasons to indent. The first is for logical scoping, where tabs do indeed make sense. An example would be

    int main(void){
        indentedStatement()
    }

However, the second is for aligning multi-line statements. Something like:

    int main(void){
        foo(bar,
            baz,
            54
        );
    }

Here, the indenting on arguments baz and 54 really should be aligned with the argument bar. If we really want to combine both use-cases that involves a mix of tabs and spaces. Tabs fist for getting the number of nested scopes, with optionally spaces to align text.

Meanwhile, mixing tabs and spaces is almost universally seen as bad. This makes sense because it is not visible where the tabs end and spaces start. This can easily lead to inconsistencies that are invisible to a writer, but are horrible for a reader with a different tab representation.

If you believe that indenting like this is a bad coding style, how do you suggest those statements should be formatted?

It's really not as hard as you make it sound, use tab for indentation, and spaces for alignment

    int main(void){
    [tab]foo(bar,
    [tab][spaces]baz,
    [tab][spaces]54
    [tab]);
    }

Put `bar` on its own line, then use tabs to indent all the arguments.

    foo(
        bar,
        baz,
        54
    );

Optionally the closing `);` could follow the last argument.

The solution is to mix tabs and spaces; most editors can be configured to clearly show tabs. Indent with tabs, then align with spaces. Never place a tab after a space.

If you mess up, no big problem, someone else will see it and fix it. People screw up space-alignment all the time anyway.

Or, better still, don't visually align stuff. It's annoying as hell to maintain unless you use an IDE, and has a tendency to bunch stuff up toward the right margin when function names grow long. Just start the argument list indented by one tab stop on the next line. More visually consistent too.

It's way better than alignment with spaces. Simple rules for indentation of multi-line statements have less diff noise and subjectivity than aligning with spaces.

The only exception is Lisp...because it's lisp.

You're quite right, and I address that here: https://news.ycombinator.com/item?id=20381842

tl;dr don't do that because it's ugly to conflate two purposes of indentation in this way, but if you absolutely must conflate them then do so explicitly with tabs and spaces, as you describe, and use an editor which makes the difference visually apparent.

This actually boils down to an argument in favor of tabs, because the additional semantic information allows the editor to present you more visual cues to work with.

Spaces always work online in a text box whilst spaces do not.

Pressing tab in here doesn't give me an indent but changes focus.

  But spaces always work

Leading spaces here don't specifically give you an indent, they give you a formatted code block. I don't really see how this is relevant either way, you're not sharing code with your coworkers in a browser text box on HN. Use whatever you want here.

Here was merely an example. Sometimes I might want to use a web based IDE like edit file on GitHub or GitLab.

Both of those support using the tab key to indent with tabs. In fact you can even configure the GitHub one to use tabs or spaces.

That's unfortunate but it's only a keybinding problem - you can paste tabs in text boxes just fine (whether the website does something sensible with the character is a separate issue; HN doesn't).

Hopefully you're not doing vast amounts of coding in a web browser text box anyway. If it's a more sophisticated web-based IDE, that keybinding can trivially be overridden in javascript.

Yeah but, in a GUI, pressing Tab is supposed to change focus, not to insert a Tab character.

And the arrow keys and the spacebar are supposed to scroll, and backspace is supposed to go back a page, and enter is supposed to submit, and forward slash is supposed to open a search box. We manage, by making our software intelligently adapt to the context. Most of the time, ability to insert a tab character is less important than the ability to change focus. In a dedicated source code editor, however, this is not the case.

Using tabs or spaces has nothing at all to do with "pressing tab". You can press the tab key and get spaces, or obtain tabs without pressing the tab key. They are completely orthogonal issues.

Reply on news.ycombinator.com