5 ms·
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 e
by dTal 7y ago
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.
- vanderZwan 7y ago> 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!
- rocqua 7y agoThe 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?
- NeutronStar 7y agoIt'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]); }
- Thiez 7y agoPut `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.
- colanderman 7y agoThe 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.
- timw4mail 7y agoIt'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.
- dTal 7y agoYou're quite right, and I address that here: https://news.ycombinator.com/item?id=20381842 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.
- dalore 7y agoSpaces 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
- scrollaway 7y agoLeading 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.
- dalore 7y agoHere was merely an example. Sometimes I might want to use a web based IDE like edit file on GitHub or GitLab.
- scrollaway 7y agoBoth 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.
- dTal 7y agoThat'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.
- zephyrfalcon 7y agoYeah but, in a GUI, pressing Tab is supposed to change focus, not to insert a Tab character.
- 7y ago