5 ms·

Been saying for years that tabs are an accessibility feature. It's good to see a thread get some traction. I've never understood why people -- logical people; p

Been saying for years that tabs are an accessibility feature. It's good to see a thread get some traction. I've never understood why people -- logical people; programmers -- are so religious about spaces, especially in the Python community. A while back I tried to make the case to the author of Black (The python community's excellent auto-formatter) to add a "--use-tabs" option. I was not successful; I had to fork Black to be able to use it. https://github.com/jleclanche/tan https://github.com/jleclanche/tan

theon144 7y ago
To be fair, Black's entire raison d'etre seems to be to not provide configuration unless absolutely necessary (for syntantic reasons, I'd imagine).
- scrollaway 7y ago
  And yet it does provide some configuration. :) Black has the same philosophy as Prettier, which does provide a --use-tabs option. And the whole "hey, accessibility" thing kind of rings as "absolutely necessary" in my book. I've had a bunch of people thank me for my fork because they wanted to use Black, but couldn't because they either preferred tabs or were required to use tabs. Similar reasons why Black provides a configurable max line length. I mean, I've had this argument with the author, I don't exactly want to go over it again :) The official reasoning for not including tabs as an option is that "tabs for indentation are the devil". https://github.com/python/black/issues/47 https://github.com/python/black/issues/47
  - vanderZwan 7y ago
    > "tabs for indentation are the devil" Well, at least the author's honest about this being a religious argument, I guess
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 ago
  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?
  - NeutronStar 7y ago
    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]); }
  - Thiez 7y ago
    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.
  - colanderman 7y ago
    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.
jasode 7y ago
>I've never understood why people -- logical people; programmers -- are so religious about spaces, I'm not religious about spaces and I 100% agree with the logic of tabs superiority because of its semantics of indentation. That said, I use often use the inferior spaces because it's the "least worst" option in a messy world where multiple programmers write inconsistent code with different tab settings of 2,4,8. (I wrote a similar previous comment.[1]) E.g. In C#, I could use Spock Vulcan logic and argue that tabs are superior but the reality is that the default setting in Visual Studio is that the tab key inserts 4 spaces. Therefore "tab consistency discipline" requires everybody change their settings, or constantly run code formatting tools (which is also not a default workflow), etc. However, I notice that in collaboration on a MS Word document, it's easier to get everyone to maintain discipline with tabs because automatic numbered multilevel outlining does not work with variable spaces. Everybody editing the document notices the headings not getting renumbered which means the Table-of-Contents regeneration is also broken. This contrasts with programmers using various text editors with their inconsistent tab preferences of 2,4,8 leading to inconsistent code formatting and they don't realize that others see inconsistent formatting. [1] https://news.ycombinator.com/item?id=12397246 https://news.ycombinator.com/item?id=12397246
- dTal 7y ago
  Why do different tab settings result in inconsistent formatting? Surely it always inserts a \t into the file. Seems to me the only way it's inconsistent on-disk is if those people are actually writing spaces (and not agreeing on how many). If you're not going to agree on an indentation width, surely tabs are superior? Conversely, if you're going to mandate an indentation width, surely it's just as easy to do that with tabs as with spaces - and more flexible?
  - jasode 7y ago
    >Why do different tab settings result in inconsistent formatting? Because some programmers also use tabs for cosmetic alignment. (The other thread also illustrates some examples.) It doesn't matter if that's semantically incorrect. A lot of it has to do with muscle memory; the programmer's brain is on automatic pilot and therefore the left pinky finger just taps <tab><tab> ... to line up function parameters or the values of variables. This type of alignment is not always round-trip perfectly preserved with code formatting utilities that covert tabs->spaces->tabs. (In other words, some programmers sometimes presses <tab> not for its semantic meaning but as a mechanical shortcut to quickly move the cursor to the right an arbitrary amount.) One can make an airtight case for the rational purity of tabs but the problem is that the real world doesn't always want to cooperate.
softawre 7y ago
Nice fork, great name for it ;)
- scrollaway 7y ago
  Psych fan? :)

theon144 7y ago

To be fair, Black's entire raison d'etre seems to be to not provide configuration unless absolutely necessary (for syntantic reasons, I'd imagine).

scrollaway 7y ago
And yet it does provide some configuration. :) Black has the same philosophy as Prettier, which does provide a --use-tabs option. And the whole "hey, accessibility" thing kind of rings as "absolutely necessary" in my book. I've had a bunch of people thank me for my fork because they wanted to use Black, but couldn't because they either preferred tabs or were required to use tabs. Similar reasons why Black provides a configurable max line length. I mean, I've had this argument with the author, I don't exactly want to go over it again :) The official reasoning for not including tabs as an option is that "tabs for indentation are the devil". https://github.com/python/black/issues/47 https://github.com/python/black/issues/47
- vanderZwan 7y ago
  > "tabs for indentation are the devil" Well, at least the author's honest about this being a religious argument, I guess

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 ago
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?
- NeutronStar 7y ago
  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]); }
- Thiez 7y ago
  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.
- colanderman 7y ago
  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.

jasode 7y ago

>I've never understood why people -- logical people; programmers -- are so religious about spaces, I'm not religious about spaces and I 100% agree with the logic of tabs superiority because of its semantics of indentation. That said, I use often use the inferior spaces because it's the "least worst" option in a messy world where multiple programmers write inconsistent code with different tab settings of 2,4,8. (I wrote a similar previous comment.[1]) E.g. In C#, I could use Spock Vulcan logic and argue that tabs are superior but the reality is that the default setting in Visual Studio is that the tab key inserts 4 spaces. Therefore "tab consistency discipline" requires everybody change their settings, or constantly run code formatting tools (which is also not a default workflow), etc. However, I notice that in collaboration on a MS Word document, it's easier to get everyone to maintain discipline with tabs because automatic numbered multilevel outlining does not work with variable spaces. Everybody editing the document notices the headings not getting renumbered which means the Table-of-Contents regeneration is also broken. This contrasts with programmers using various text editors with their inconsistent tab preferences of 2,4,8 leading to inconsistent code formatting and they don't realize that others see inconsistent formatting. [1] https://news.ycombinator.com/item?id=12397246 https://news.ycombinator.com/item?id=12397246

dTal 7y ago
Why do different tab settings result in inconsistent formatting? Surely it always inserts a \t into the file. Seems to me the only way it's inconsistent on-disk is if those people are actually writing spaces (and not agreeing on how many). If you're not going to agree on an indentation width, surely tabs are superior? Conversely, if you're going to mandate an indentation width, surely it's just as easy to do that with tabs as with spaces - and more flexible?
- jasode 7y ago
  >Why do different tab settings result in inconsistent formatting? Because some programmers also use tabs for cosmetic alignment. (The other thread also illustrates some examples.) It doesn't matter if that's semantically incorrect. A lot of it has to do with muscle memory; the programmer's brain is on automatic pilot and therefore the left pinky finger just taps <tab><tab> ... to line up function parameters or the values of variables. This type of alignment is not always round-trip perfectly preserved with code formatting utilities that covert tabs->spaces->tabs. (In other words, some programmers sometimes presses <tab> not for its semantic meaning but as a mechanical shortcut to quickly move the cursor to the right an arbitrary amount.) One can make an airtight case for the rational purity of tabs but the problem is that the real world doesn't always want to cooperate.

softawre 7y ago

Nice fork, great name for it ;)

scrollaway 7y ago
Psych fan? :)