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
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.
>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.
The reason it's more accessible is because it's The Right Way, in the same way that a text file is more accessible than a screenshot of that text file. Indentation is a semantic property, not a visual one.
Indentation is semantic only in Python (which incidentally uses spaces). In any other language it's a purely visual property - the code works the same regardless of indentation.
"but editors will give you 4 spaces when you press tab" - yes, this one is a BS argument
But I've given up on discussing with people completely refractory to discussion, the cult of space indentation is strong
There is one consistency I'll concede: the consistency between indentation and tidying up the code, mixing tabs and spaces there is awful (as any mix of tabs and spaces are)
Well, as always, it is more nuanced. If you are simply indenting code, tabs are certainly the semantically correct way, one level of identation, one tab. But sometimes indentation by one level just doesn't cut, sometimes you want finer control for aligning things, for example to highlight common structures in expressions that just differ by some varaibles with unequal lengths. And this is where using tabs and mixing them with spaces falls apart and it fall apart in a spot where you think it is important to have good alignment in order to make the code easier to understand and modify in order to avoid bugs.
I've been a tab user since forever. The biggest issue with using spaces is not how much you indent, it's the bad pattern of aligning stuff vertically beyond a simple N-level indent.
Using spaces to align stuff on multiple lines causes multiple problems.
Any changes will affect surrounding lines. This adds busy-work to realign everything, especially if you're not using a fancy editor plugin to do it. It also makes for bigger diffs, which add pointless noise when reading diffs, and potentially unneccessary merge/rebase conflicts.
It's also assuming that the text is displayed in a monospaced font. A (very rare) few of us like to code with good looking proportianally spaced fonts instead of awkwardly spaced typewriter fonts.
I've been a die hard 2-space indent person for well over a decade, but this is an argument I simply can't ignore and I feel compelled to reconsider my position. Thanks for sharing this!
If everyone uses tabs for indentation, then you can configure your editor to display that as 2 characters width, while the people who prefer 4 or 8 can do the same. No one needs to argue about how many columns of indentation there will be (1/2/4/8) since it’s specified in text semantically and displayed individually. No one needs to be die-hard N-space-ists since everyone can have their way simultaneously. Even code that wasn’t written by people who prefer your 2-column indent style (if they would otherwise be using spaces) will look that way to you. Everyone wins!
I used to be a “tab person” when I started using python in 2001 - after all, it makes more logical sense and it saves bytes, what’s not to like?
And then the world duly standardized on 4-spaces-per-indent.
So I’ve long given up and just gone with the flow. Unless big projects switch to tabs in a coordinated manner, to make a big statement, this matter is unlikely to ever be reevaluated.
That's a very good argument, but I have another one, also often dismissed: if you navigate using your keyboard's arrow keys (which can be more productive than mouse/trackpad) then jumping over tabs to reach text is just way faster. Spaces kind of force you to use your mouse more.
That's actually one of my arguments against tabs --- the sudden "acceleration" of the cursor when it runs through a series of tabs is quite disorienting because it means you can't estimate as easily how long it'll take to get to a certain point.
I do not really care for tabs vs spaces, except in Python, where tabs are obviously the appropriate choice. For conceptual simplicity and orthogonality, if you want to treat python programs as text files, and deal with them using standard text processing tools, it is much more comfortable when the indentation is marked by a single character.
Apart from that, I never cared if people used spaces in other programming languages (as long as it was 8 spaces per level, of course). But this reddit post highlights an important reason to promote tabs everywhere, not only in Python.
I agree completely. Elastic tabstops are such an elegant solution to the whole debate. It turns the tab character into what it should be semantically, a character to denote alignment, just as it is used in a wysiwyg word processor.
When supported by the editor, it also allows the user to align columns using a proportional font instead of the fixed-with fonts we have to use now.
The concept has been discussed on HN earlier, but the accessibility argument is something that I hadn't considered or seen anyone discuss.
these guys have serious problems using codebases with spaces, they have to convert, do their work, and then unconvert before committing
I used to work for a company that had automatic formatting on checkin/checkout --- everyone had his/her own formatting preferences (tabs/spaces and how many was one of them), which deviated slightly from the "official" one, but the process was basically completely automatic.
My personal preference is one space --- files are just as small as with tabs, and the column counter of the editor also directly corresponds to the indent level.
Also, the lack of capitalisation and run-on sentences in a post arguing about accessibility is a bit ironic.
Use tabs for indentation, space for alignment, why do it anyway else?
I especially like Linus Torvalds view on indentation:
"Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.
Rationale: The whole idea behind indentation is to clearly define where a block of control starts and ends. Especially when you've been looking at your screen for 20 straight hours, you'll find it a lot easier to see how the indentation works if you have large indentations.
Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program."
Something that I feel gets overlooked in tabs versus spaces is that a tab generally has a specific semantic meaning (increase indent by one) whereas a space's meaning depends on how many spaces you are using to indent and a single space has no meaning on its own (unless you are indenting using only one space).
As a side note: I wish that JavaScript had a utility like the "indent" utility in Unix for precisely styling C code. Prettier is close; however, it cannot be customized in the detail that I would like.
I kind of feel that source code needs to take a tip from HTML and apply a style-sheet. Have editors parse the code and display according to the user's preferences.
I generally don't like using tabs, as I find having two characters for whitespace leads to annoying inconsistencies. However, were a team member request I use tabs for accessibility reasons, I would have no issue complying.
That aside, I don't feel that this particular argument any stronger than any personal preference, let alone some kind of be-all final reason.
Generally whenever more than one space is used consecutively it is intended for indentation purposes - thus an equivalent solution to the accessibility problem is to just configure the editor to render consecutive spaces differently.
The post author calls for more editors to support adjusting tab widths showing that using tabs isn't automatically an accessibility win - spaces users could just as easily call for more editors to support custom ligatures to help the visually impaired.
I actually find having a separate character for indentation is a strength of tabs rather than a detriment. Tabs tell you how the lines in your program relate to one another, and spaces tell you how things relate within a given line.
On top of that, I think the strongest argument for tabs is efficiency. space-indented code uses 3 times as many bytes to represent a level of indentation than tab-delimited code. That might not seem like a lot, but spread over all the commits in all the codebases using spaces, it seems pointless to use all that extra disk space for no reason.
I think the real problem is that the default tab width for web interfaces is 8 spaces. If it were a more reasonable 4 characters wide, I doubt it would even be an issue.
Despite adding a valid perspective, this is mostly clickbait.
A file is just a storage format. The real issue is that IDE's don't render files according to user preferences, be them TABs or spaces, or PascalCase vs snake-case. When saving they convert back. No need to "get everybody on the same page" and in the process create winners and losers.
Unlike laws (or like laws), technology has the capacity to create win-win situations. This is a good example. So the real question is why we insist on debates, instead of actually doing our jobs. Congress can only solve so much.
That is a pretty good point. As a rubyist, I always use and advocate two spaces - but if I ever find myself on a team with visual impairments, I'll be sure to ask whether tabs would be useful to the team. I'm a big believer that Team-level consistency is far more important than Universe-level consistency, and silver bullets kill.
That said, I'm intrigued - surely this must be a solved problem at this point? Anybody aware of any good text editors / editor plugins that allow you to modify the visual spacing of start-of-line spaces?
It is a solved problem! Just use tabs. Almost every editor supports adjustable-width tabs. Why go out of your way to avoid tabs, and then make spaces behave like tabs?
It’s safer to assume that any code you write will at one point be maintained by somebody with a visual impairment even if there’s not currently a team member with an impairment.
An excellent argument. I've been mostly agnostic about the tabs-vs-spaces debate, as long as we just pick one and stick with it everywhere consistently and never ever mix the two. I've had this feeling lately that maybe tabs might be more appropriate than spaces, but never felt strongly about it, and everybody has settled on spaces, so lets just stick with that.
But in light of this argument, yes, lets move to tabs instead. More control for the user in how you actually display them.
[+] [-] Sahhaese|6 years ago|reply
https://news.ycombinator.com/item?id=20341354
[+] [-] yitchelle|6 years ago|reply
[+] [-] scrollaway|6 years ago|reply
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
[+] [-] dTal|6 years ago|reply
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.
[+] [-] jasode|6 years ago|reply
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
[+] [-] theon144|6 years ago|reply
[+] [-] softawre|6 years ago|reply
[+] [-] dTal|6 years ago|reply
[+] [-] viraptor|6 years ago|reply
Depending on style in can be both.
[+] [-] Grue3|6 years ago|reply
[+] [-] raverbashing|6 years ago|reply
"but editors will give you 4 spaces when you press tab" - yes, this one is a BS argument
But I've given up on discussing with people completely refractory to discussion, the cult of space indentation is strong
There is one consistency I'll concede: the consistency between indentation and tidying up the code, mixing tabs and spaces there is awful (as any mix of tabs and spaces are)
[+] [-] danbruc|6 years ago|reply
[+] [-] maskros|6 years ago|reply
Using spaces to align stuff on multiple lines causes multiple problems.
Any changes will affect surrounding lines. This adds busy-work to realign everything, especially if you're not using a fancy editor plugin to do it. It also makes for bigger diffs, which add pointless noise when reading diffs, and potentially unneccessary merge/rebase conflicts.
It's also assuming that the text is displayed in a monospaced font. A (very rare) few of us like to code with good looking proportianally spaced fonts instead of awkwardly spaced typewriter fonts.
[+] [-] mstade|6 years ago|reply
[+] [-] Pyxl101|6 years ago|reply
If everyone uses tabs for indentation, then you can configure your editor to display that as 2 characters width, while the people who prefer 4 or 8 can do the same. No one needs to argue about how many columns of indentation there will be (1/2/4/8) since it’s specified in text semantically and displayed individually. No one needs to be die-hard N-space-ists since everyone can have their way simultaneously. Even code that wasn’t written by people who prefer your 2-column indent style (if they would otherwise be using spaces) will look that way to you. Everyone wins!
[+] [-] toyg|6 years ago|reply
And then the world duly standardized on 4-spaces-per-indent.
So I’ve long given up and just gone with the flow. Unless big projects switch to tabs in a coordinated manner, to make a big statement, this matter is unlikely to ever be reevaluated.
[+] [-] yitchelle|6 years ago|reply
I know the Linux kernel has an 8 spaces requirement. Code has been known to be rejected based on this violation.
[+] [-] mojuba|6 years ago|reply
[+] [-] xiwenc|6 years ago|reply
[+] [-] userbinator|6 years ago|reply
[+] [-] mysterydip|6 years ago|reply
[+] [-] IshKebab|6 years ago|reply
[+] [-] enriquto|6 years ago|reply
Apart from that, I never cared if people used spaces in other programming languages (as long as it was 8 spaces per level, of course). But this reddit post highlights an important reason to promote tabs everywhere, not only in Python.
[+] [-] IshKebab|6 years ago|reply
[+] [-] _ZeD_|6 years ago|reply
http://nickgravgaard.com/elastic-tabstops/
[+] [-] daghoidahl|6 years ago|reply
When supported by the editor, it also allows the user to align columns using a proportional font instead of the fixed-with fonts we have to use now.
The concept has been discussed on HN earlier, but the accessibility argument is something that I hadn't considered or seen anyone discuss.
[+] [-] userbinator|6 years ago|reply
I used to work for a company that had automatic formatting on checkin/checkout --- everyone had his/her own formatting preferences (tabs/spaces and how many was one of them), which deviated slightly from the "official" one, but the process was basically completely automatic.
My personal preference is one space --- files are just as small as with tabs, and the column counter of the editor also directly corresponds to the indent level.
Also, the lack of capitalisation and run-on sentences in a post arguing about accessibility is a bit ironic.
[+] [-] JacKTrocinskI|6 years ago|reply
I especially like Linus Torvalds view on indentation:
"Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.
Rationale: The whole idea behind indentation is to clearly define where a block of control starts and ends. Especially when you've been looking at your screen for 20 straight hours, you'll find it a lot easier to see how the indentation works if you have large indentations.
Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program."
https://github.com/torvalds/linux/blob/master/Documentation/...
[+] [-] harimau777|6 years ago|reply
As a side note: I wish that JavaScript had a utility like the "indent" utility in Unix for precisely styling C code. Prettier is close; however, it cannot be customized in the detail that I would like.
[+] [-] curiousgal|6 years ago|reply
[+] [-] devit|6 years ago|reply
[+] [-] billpg|6 years ago|reply
[+] [-] robin_reala|6 years ago|reply
[+] [-] kranner|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] swerner|6 years ago|reply
Not just tabs vs spaces, but also camel case vs underscore, line length, etc.
[+] [-] ablomen|6 years ago|reply
Tabs for indentation, spaces for alignment looks to me like the best of both worlds.
[+] [-] C1sc0cat|6 years ago|reply
The old school 80 column fixed layouts like Fortran had did have its advantages.
[+] [-] gopiandcode|6 years ago|reply
That aside, I don't feel that this particular argument any stronger than any personal preference, let alone some kind of be-all final reason.
Generally whenever more than one space is used consecutively it is intended for indentation purposes - thus an equivalent solution to the accessibility problem is to just configure the editor to render consecutive spaces differently.
The post author calls for more editors to support adjusting tab widths showing that using tabs isn't automatically an accessibility win - spaces users could just as easily call for more editors to support custom ligatures to help the visually impaired.
[+] [-] skohan|6 years ago|reply
On top of that, I think the strongest argument for tabs is efficiency. space-indented code uses 3 times as many bytes to represent a level of indentation than tab-delimited code. That might not seem like a lot, but spread over all the commits in all the codebases using spaces, it seems pointless to use all that extra disk space for no reason.
I think the real problem is that the default tab width for web interfaces is 8 spaces. If it were a more reasonable 4 characters wide, I doubt it would even be an issue.
[+] [-] pseudalopex|6 years ago|reply
The author calls for more websites to support adjusting tab widths. What editor doesn't?
[+] [-] childintime|6 years ago|reply
A file is just a storage format. The real issue is that IDE's don't render files according to user preferences, be them TABs or spaces, or PascalCase vs snake-case. When saving they convert back. No need to "get everybody on the same page" and in the process create winners and losers.
Unlike laws (or like laws), technology has the capacity to create win-win situations. This is a good example. So the real question is why we insist on debates, instead of actually doing our jobs. Congress can only solve so much.
[+] [-] undecisive|6 years ago|reply
That said, I'm intrigued - surely this must be a solved problem at this point? Anybody aware of any good text editors / editor plugins that allow you to modify the visual spacing of start-of-line spaces?
[+] [-] dTal|6 years ago|reply
[+] [-] themarkn|6 years ago|reply
[+] [-] mcv|6 years ago|reply
But in light of this argument, yes, lets move to tabs instead. More control for the user in how you actually display them.