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
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
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?
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.
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.
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.
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.
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.
>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.
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?
>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.
In the real world, there's people who benefit from the accessibility of tabs. It's not that hard to avoid alignment (which most devs recommend against for other reasons such as maintenance costs and git diff noise), I've been doing so for fifteen years without issues.
> the reality is that the default setting in Visual Studio is that the tab key inserts 4 spaces
I don't use VS so I'm not sure about this specific example, but from my experience, if you have to fight all your colleagues' editor defaults, you're going to have a hard time.
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.
That’s a good point. If you need specific visual alignment with an arbitrary number of characters on the previous line, then spaces are appropriate. Tabs should be used for the initial semantic indentation then spaces for additional visual indentation beyond that.
(Whether visual alignment of this sort is desirable is a different question. If you want it then spaces are appropriate.)
It breaks a fundamental assumption, which is that indent depth strictly reflects code nesting depth.
If you're going to do that, the "correct" way would be to indent each parameter with tabs to the same depth as the function declaration, and then use spaces to take up the rest of the space (i.e. the width of the function declaration). Which is admittedly ugly - but it's ugly because it reflects the ugliness of misusing indentation for alignment. It's slightly less ugly if you use an editor that displays tabs and spaces differently - Kate/Kdevelop use a nice discreet » character for each level of indentation:
I think all code styles which use arbitrary vertical alignment are strictly inferior to ones which use newlines and indents. The simple fact that changing `something` to `somethingElse` causes a 3-line diff is enough to convince me, but when we add the idea that hard tabs are better for a11y, it makes arbitrary vertical alignment seem completely untenable to me.
For that you would use tabs to align to the ‘def’ statement and spaces for the parameters. That way it keeps lining up if someone else uses different tab widths.
Move "with aligned," to it's own line and you don't need visual alignment at all, it's all semantic. Surely the extra line feed is worth elimination a whole category of alignment in code.
"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)
Yeah, it's pretty bad, as a novice I once opened a file in Vim, I used tabs for indenting, as I do in vscode (for Python code) and I get all sorts of errors, very annoying. Turns out, I never really was using tabs in vscode. And it's already in everything I wrote (I found out about this debat really late in my self taught coding career). Guess the choice was made for me.
> " editors will give you 4 spaces when you press tab"
but what kind of editors do people use? Any normal editor supports autoindentation and you never get to press the damn tab key. In vim for example, if you set autoindent then you can map TAB to ESC, which is much closer.
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 don't see the issue. You shouldn't need to align things with spaces at the beginning of lines, since they're already aligned. And you shouldn't be using tabs for alignment anywhere else in the line; they're indents. So where's the "mixing"? Tabs until the first non-whitespace character on a line, spaces anywhere else you like.
The mixing usually happens by accident, you copy and paste bits and pieces, you need a lot of spaces for aligning things and just hit tab, you want to break the indentation rules by a space or two for readability, ... I am not saying that it can not work if you are careful enough, proabably with visible whitespace on all the time, in practice however it will become messy most of the time, especially as people working on a code base come and go.
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.
I think you've misunderstood the use of semantic here - it's semantic for all text files. Instead of describing very exactly 'put 8 spaces here' you're saying 'for some reason this line needs to be indented once, take this information display this as you wish.'
Indentation is semantic has in it carry a meaning. We are not talking about how a specific language use it.
As for Python, it doesn't use space. It can use both spaces and tabs (but not mixed within the same file). It's just that PEP-8 require spaces, but not every project/library follow PEP-8.
In those languages where it is not semantic, proper indentation still gives visual clues to the semantics: With proper indentation one can read programs in lots of languages even without their specific semantic markers. A simple way to see this is to configure your editor's syntax highlighting to use the background color for parenthesis, semicolons or whatever the markers are in your language of choice.
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!
Sometimes I wonder if I'm the only person in the world with a preference for 3-character width tabs.
I also wonder if I can ever bring up this topic in public without being called perverse by other programmers. People get really weirdly religious about this.
Can be and probably usually is. However, funnily enough, I have a language-dependent preference: 2 spaces or Lisp-like languages, 4 spaces for all others.
As the other comment suggested it's language independent. For me, three characters have enough width to be easy to visually distinguish from plain spaces, and the occasional typo, but still easy to keep track of with multiple indentations.
I do suspect that Fitt's Law[0] applies to the question of ideal indentation width though. In that case there is a trade-off between trying to minimize the number of characters for less distance, since that makes it easier to "hit the target" with your reading saccade, and having enough distance to make sure indentation has a visually distinct gap from plain spaces. However, the sweet spot of that trade-off is undoubtedly very personal and dependent on many factors.
The problem is this only works if everyone is using tabs. As long as there's significant groups of people using spaces you'll need tooling to convert it to your needs anyway.
I see more point in making this tooling easier to use and more accessible.
Sure, this is the common argument and also the only I typically just ignored in the past simply because I just read it as a debate of preference, and I just care to spend my time with such nonsense – call me an inconsiderate prick if you will, but I picked 2-space indentation and stuck with it.
But I never considered the accessibility aspect of it, and inconsiderate as I may be towards the preference of my fully abled colleagues, I definitely don't want to make life harder for my colleagues with accessibility needs. I also believe more accessibility benefits everyone, but it never occurred to me that tabs are more accessible than spaces until I read this thread.
Call me a convert – I'm now going to spend time changing my configurations and workflow to work with tabs instead of spaces, wherever possible. Thanks!
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.
Linux kernel has 1 tab, which many/most would map to 8 (including me). Mapping to 8 has (and not 2 and 4) becomes relevant if you have line size limits.
I'm not sure that indentation should count towards line size limits at all, or at least not more than 1 character per indent. If it doesn't fit on your screen, you can change your tab width until it does.
From memory go fmt will use both tabs and spaces when formatting but it uses tabs for indentation from the left margin and uses spaces for some alignment of variables - so it doesn't introduce any crazy interleaving of tabs and spaces which I like.
Correct. And frankly, that's the logical choice. It allows to use different tabwidth for representation, while still aligning variables correctly with spaces. But this only works when you enforce an autoformatter, and way too few languages have a standardized autoformat.
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.
Yes, editors usually provide a function for that. But a lot of the times, say you go down where code is indented one level deeper and all you need is to just go right once. That's always faster than any combination of keys your editor can provide.
Many editors skip the whole indentation level when using arrows. The actual encoding is irrelevant for them. Atom calls this setting "atomic soft tabs", I believe.
That’s a great point, but learning arrow key function varies based on the app I use. So if I have to learn arrow to move around indents, I may as well learn the command to move between words.
I struggle with trying to get others to change their files because a particular program I like and use a lot handles their file a certain way. This reminds me of the olden days of the old Microsoft way where the solution seemed to be around making every app respond in the way way so it was possible to guarantee what arrow does across all apps.
But that way lost and now files are used in all sorts of weird wonderful ways.
This is not really true; ‘w’ is one row up from the home row and is easily accessible with the middle or ring finger. An arrow key is a hand-shift or an awkward pinky stretch away. Vim keybindings were explicitly designed to be simpler than arrow keys once you’ve gotten over the learning curve.
I haven't done any iOS development, so perhaps I'm expecting too much; but surely there is an IDE that has a vim-mode plugin? Every IDE/editor I've used—all JetBrains products, Atom, Visual Studio, Eclipse...—has a vim plugin readily available. They're rarely perfect (they tend to behave weirdly with IDE autocompletion and the like), but they're more than adequate for basic text navigation.
> but they're more than adequate for basic text navigation
I really think basic text navigation is no longer a problem since the the adoption of PC keyboards in the 1980s and 1990s. Key arrows are easy to find blindly except maybe on some screwed up laptop designs.
Perhaps our definitions of "basic text navigation" are different. I'd include capabilities such as "jump six words to the right, based on natural word boundaries" and "jump six words to the right, based on whitespace only". Oh, and "jump to the end of this statement that's enclosed by parentheses".
Not trying to start a vim-vs-whatever war here, though I suppose that's inevitable in a discussion of tabs-vs-spaces...
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.
Of course; I am a decent person. Let me just quote Linus Torvalds here:
> 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.
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."</i>
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.
>one of them uses tab-width 1 because he uses such a gigantic font-size
But if they use a "giganting font-size" to see the letters, spaces would still be proportionally gigantic. Why would they need to have custom indent size, since everything will play along with their font-size choice?
That is, why someone might want to use gigantic fonts but constraint that gigantic-ness to the actual letters, and not the indents too? Isn't it equally important to see indentation clearly?
I'm guessing when your fonts are sufficiently gigantic indents of 1 char are more than enough to see the indentation clearly (try it out). Actually, less than 1 char might be good enough or even better.
I don't know how bad the eyesight of the mentioned person was, but you may not be thinking gigantic enough. I know of people who zoom into the text to the level where maybe two-three words are visible in a line. (not all the time, but at the extreme, when reading something specific) By injecting more indent, you have to scroll a lot horizontally, or potentially miss an extra word from view if you get 2-3 extra levels of indent. If your space is at a few cm wide, it may be enough indication. Then, there are also ways of colouring indents for better visibility. (not sure if that's used for accessibility though, but it does make large indents not as important for me)
For me the challenge is part of understanding choices. I don’t think of challenge as conflict, but as a way of looking at different possibilities to learn more about why.
Agree, but I like to think of it as retrofixing your reasoning for the different view: "You tell me A, but I used to believe B because of C, D, etc. Can we investigate whether my reasoning was lacking, those are also in conflict with A, A and B are not actually in conflict, or B has a validity not influenced by A"
I like this symbolic way of putting it. I struggle with communicating that in a way that is non-threatening to people who are sensitive or defensive of their supporting beliefs E,F, etc for why A.
Because "self-selected" can be far from optimal -- lots of people self-select solutions and even insist they "work for them" that are not only sub-optimal but even medically or otherwise detrimental for them.
M-X tabify had two benefits. Firstly it more than halved assembly source paper tape. And secondly atleast Olivetti Teletype interpreted a TAB as a silent jump, instead of 8 bang-bang-bangs of empty spaces.
That's the kind of practical real life inclusivity that I think should be pushed instead of the "being offended by theoretical straw men" code of conduct nonsense.
Most decent editors can operate with tabs or spaces functioning identically, so this is mostly a moot point. With that in mind, spaces are easier to display in tools that don't handle tabs well, so using spaces is still the right approach in my estimation.
And yet these visually impaired people apparently pleaded with the OP not to take away their tabs.
Almost every program to edit text has a tab stop setting, but only the most advanced dev tools allow you the same control over spaces. Anecdotally, I’ve been struggling to get emacs to indent a certain language correctly for me (I want it to use two spaces in a place where it only uses one, I’m not really an emacs person so figuring out how to fix it is too much effort for me), if I were to switch to tabs, that would be easy: just set the tab width and be done with it. I don’t have any experience with screen readers, but it would seem to me that they should have an easier time with tabs too.
I wish the story had described the editors used by the two visually impaired coders. It seems odd that they are using an environment that doesn’t up/down convert easily. It mentioned they were forced to do this like it was a manual process.
Free IDEs like VScode do this, and it works with screen readers. Although from the description of their screens with large fonts and wide resolutions, I don’t think they were using screen readers.
Since the article is missing this bit, I can’t help that fear that all three would have benefited from knowing how to config editors to get around this problem.
Also, not every space necessarily should be converted to tabs, especially if you follow the “tabs for indentation, spaces for alignment” mentality: you will want everything up to the indentation level converted but not everything after. I’m sure some editors can do this, but many also definitely can’t. Tabs just work, everywhere.
This seems like something that could be resolved with a couple of git hooks:
post-merge: Reformat code based on local developer preference.
pre-commit: (1) Reformat code back to repository standard. (2) Revert changes that are solely whitespace-related.
I'm not aware of a tool that would do the last step automatically, but it doesn't seem like it would be too hard to implement. And perhaps (I haven't checked) git has a built-in config option to alter how it behaves for whitespace-only changes?
I’ve had success with vscode converting spaces to tabs and vice versa between open and save. Knock on wood, I haven’t had it bungle any code.
I do this because some projects like tabs, some like 2 spaces, some like 4 spaces and I like coding in a particular way that’s independent of the particular projects.
Tabs v spaces should be an argument that we are long past by now, our editors no longer bound by the limits that once fueled such arguments.
Your editor should automatically purge all whitespace and format according to your settings and language canonical form. Whether tabs, spaces, curly braces on the end of line or next line, and on and on.
Go coming with go fmt is one of the great things about the language because instantly so many color of the shed arguments were vanquished.
Thank you, I seem to be severely misinformed. Redacting my original thoughts now.
I have very poor vision and have been told by two different optomotrists that for me, personally, my vision will worsen as I strain my eyes. I never thought to wonder if this was different for anyone else -- One of those things it seems.
I was careful with my phrasing to indicate that but perhaps missed the main thought -- Perhaps a visual tool isn't the most effective nor pleasurable one for a severely visually impaired individual. Not because of any "burden" they create on others (e.g. using tabs which isn't a real burden at all) or an elitist attitude (e.g. they shouldn't code), but because of the burden I imagine sight is to them.
I wear glasses over my contacts simultaneously to work at a screen effectively -- I've been told by my optomotrists that work at the screen will continue to make my vision worse, but evidently I'm not too familiar with the correct terminology for my own impairments nor for others (and whether they always worsen). A fundamental misunderstanding on my part.
Difficulty to see (e.g. because of shortsightedness) != "strain further", especially if that implies that their vision would get worse because of that.
\t saves bytes compared to n*' '. there is literally no other reason to do this. for 'style' both can be implemented to do the same and most editors these days can replace one with the other and have configurable tabs, or 'use spaces instead of tabs' options. in reality, if for example you sent a lot of documents over the wire, or store a lot of documents on disk, using /t compared to spaces can save a lot of bytes on disk or network... (looking at the uncompressed case...)
We discussed this 5 days ago:
https://news.ycombinator.com/item?id=20341354
@dang, for dupe submission, is it possible to merge the comments from later submission into the initial submission?
We do that, but usually only when the two threads were concurrent. Five days is probably too much of a stretch.
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
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).
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
> "tabs for indentation are the devil"
Well, at least the author's honest about this being a religious argument, I guess
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
However, the second is for aligning multi-line statements. Something like:
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
Put `bar` on its own line, then use tabs to indent all the arguments.
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.
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.
>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
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?
>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.
In the real world, there's people who benefit from the accessibility of tabs. It's not that hard to avoid alignment (which most devs recommend against for other reasons such as maintenance costs and git diff noise), I've been doing so for fifteen years without issues.
> the reality is that the default setting in Visual Studio is that the tab key inserts 4 spaces
I don't use VS so I'm not sure about this specific example, but from my experience, if you have to fight all your colleagues' editor defaults, you're going to have a hard time.
Nice fork, great name for it ;)
Psych fan? :)
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 a semantic property, not a visual one.
Depending on style in can be both.
That’s a good point. If you need specific visual alignment with an arbitrary number of characters on the previous line, then spaces are appropriate. Tabs should be used for the initial semantic indentation then spaces for additional visual indentation beyond that.
(Whether visual alignment of this sort is desirable is a different question. If you want it then spaces are appropriate.)
There is a difference between indentation and alignment. Unfortunately, python chose to enforce spaces only both via the language itself and pep8.
How does the language enforce spaces only?
PEP8 was only meant as a style guide for the python standard library. Although many have unfortunately taken it as a religious text.
Oh gods please don't align like this, it's just so unreadable.
Example of what that does in practice: Lines that end up wrapping almost at the end of the soft-character-limit and look like this:
https://github.com/pennersr/django-allauth/blob/c9b31ddee81d...
IMO it depends on the language. With named parameters it is very readable, and is my preference when you have functions with lots of parameters.
It breaks a fundamental assumption, which is that indent depth strictly reflects code nesting depth.
If you're going to do that, the "correct" way would be to indent each parameter with tabs to the same depth as the function declaration, and then use spaces to take up the rest of the space (i.e. the width of the function declaration). Which is admittedly ugly - but it's ugly because it reflects the ugliness of misusing indentation for alignment. It's slightly less ugly if you use an editor that displays tabs and spaces differently - Kate/Kdevelop use a nice discreet » character for each level of indentation:
The last line is visually aligned, but the semantic depth is the same.
I'd go with
Eh? This is fairly normal in most languages. Although in the example given I might have moved the .dispatch to the next line instead.
I think all code styles which use arbitrary vertical alignment are strictly inferior to ones which use newlines and indents. The simple fact that changing `something` to `somethingElse` causes a 3-line diff is enough to convince me, but when we add the idea that hard tabs are better for a11y, it makes arbitrary vertical alignment seem completely untenable to me.
For that you would use tabs to align to the ‘def’ statement and spaces for the parameters. That way it keeps lining up if someone else uses different tab widths.
Move "with aligned," to it's own line and you don't need visual alignment at all, it's all semantic. Surely the extra line feed is worth elimination a whole category of alignment in code.
You are 100% right
"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)
Yeah, it's pretty bad, as a novice I once opened a file in Vim, I used tabs for indenting, as I do in vscode (for Python code) and I get all sorts of errors, very annoying. Turns out, I never really was using tabs in vscode. And it's already in everything I wrote (I found out about this debat really late in my self taught coding career). Guess the choice was made for me.
> " editors will give you 4 spaces when you press tab"
but what kind of editors do people use? Any normal editor supports autoindentation and you never get to press the damn tab key. In vim for example, if you set autoindent then you can map TAB to ESC, which is much closer.
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 don't see the issue. You shouldn't need to align things with spaces at the beginning of lines, since they're already aligned. And you shouldn't be using tabs for alignment anywhere else in the line; they're indents. So where's the "mixing"? Tabs until the first non-whitespace character on a line, spaces anywhere else you like.
The mixing usually happens by accident, you copy and paste bits and pieces, you need a lot of spaces for aligning things and just hit tab, you want to break the indentation rules by a space or two for readability, ... I am not saying that it can not work if you are careful enough, proabably with visible whitespace on all the time, in practice however it will become messy most of the time, especially as people working on a code base come and go.
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.
I think you've misunderstood the use of semantic here - it's semantic for all text files. Instead of describing very exactly 'put 8 spaces here' you're saying 'for some reason this line needs to be indented once, take this information display this as you wish.'
Indentation is semantic has in it carry a meaning. We are not talking about how a specific language use it.
As for Python, it doesn't use space. It can use both spaces and tabs (but not mixed within the same file). It's just that PEP-8 require spaces, but not every project/library follow PEP-8.
> Indentation is semantic only in Python
And in Haskell. And in Nim. And in Haml. And in Sass. And in YAML.
https://en.wikipedia.org/wiki/Off-side_rule#Off-side_rule_la...
In those languages where it is not semantic, proper indentation still gives visual clues to the semantics: With proper indentation one can read programs in lots of languages even without their specific semantic markers. A simple way to see this is to configure your editor's syntax highlighting to use the background color for parenthesis, semicolons or whatever the markers are in your language of choice.
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!
Here’s another argument:
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!
> (1/2/4/8)
Sometimes I wonder if I'm the only person in the world with a preference for 3-character width tabs.
I also wonder if I can ever bring up this topic in public without being called perverse by other programmers. People get really weirdly religious about this.
Oh, how come?
What language are you using where 3-spaces-wide tabs are more comfortable?
An indentation preference can be largely language independent.
Can be and probably usually is. However, funnily enough, I have a language-dependent preference: 2 spaces or Lisp-like languages, 4 spaces for all others.
As the other comment suggested it's language independent. For me, three characters have enough width to be easy to visually distinguish from plain spaces, and the occasional typo, but still easy to keep track of with multiple indentations.
I do suspect that Fitt's Law[0] applies to the question of ideal indentation width though. In that case there is a trade-off between trying to minimize the number of characters for less distance, since that makes it easier to "hit the target" with your reading saccade, and having enough distance to make sure indentation has a visually distinct gap from plain spaces. However, the sweet spot of that trade-off is undoubtedly very personal and dependent on many factors.
[0] https://en.wikipedia.org/wiki/Fitts's_law
You are not alone! Four is too much and two is too little for me visually, three is just right.
The problem is this only works if everyone is using tabs. As long as there's significant groups of people using spaces you'll need tooling to convert it to your needs anyway.
I see more point in making this tooling easier to use and more accessible.
Sure, this is the common argument and also the only I typically just ignored in the past simply because I just read it as a debate of preference, and I just care to spend my time with such nonsense – call me an inconsiderate prick if you will, but I picked 2-space indentation and stuck with it.
But I never considered the accessibility aspect of it, and inconsiderate as I may be towards the preference of my fully abled colleagues, I definitely don't want to make life harder for my colleagues with accessibility needs. I also believe more accessibility benefits everyone, but it never occurred to me that tabs are more accessible than spaces until I read this thread.
Call me a convert – I'm now going to spend time changing my configurations and workflow to work with tabs instead of spaces, wherever possible. Thanks!
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.
Would be interesting to see a table of spaces per indent vs language or Project.
I know the Linux kernel has an 8 spaces requirement. Code has been known to be rejected based on this violation.
Linux kernel has 1 tab, which many/most would map to 8 (including me). Mapping to 8 has (and not 2 and 4) becomes relevant if you have line size limits.
That struck me as odd surely 8 is the norm - a holdover from typewriters
I'm not sure that indentation should count towards line size limits at all, or at least not more than 1 character per indent. If it doesn't fit on your screen, you can change your tab width until it does.
Linux kernel is 1 tab
Golang also mandates tabs I think
From memory go fmt will use both tabs and spaces when formatting but it uses tabs for indentation from the left margin and uses spaces for some alignment of variables - so it doesn't introduce any crazy interleaving of tabs and spaces which I like.
Correct. And frankly, that's the logical choice. It allows to use different tabwidth for representation, while still aligning variables correctly with spaces. But this only works when you enforce an autoformatter, and way too few languages have a standardized autoformat.
I remember seeing this a while ago: https://ukupat.github.io/tabs-or-spaces/ which is basically what you're talking about.
Of note are Go and a few others, Go because it generally uses gofmt, which uses tabs, as far as I understand.
Ruby standardized on 2 spaces per indentation level.
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.
I tend to use ctrl+left or right to skip to the next non-whitespace character (depending on your editor).
Yes, editors usually provide a function for that. But a lot of the times, say you go down where code is indented one level deeper and all you need is to just go right once. That's always faster than any combination of keys your editor can provide.
Many editors skip the whole indentation level when using arrows. The actual encoding is irrelevant for them. Atom calls this setting "atomic soft tabs", I believe.
Assuming you're not using some very basic text editor; good ones have skip word. For instance 'w' in vim, or 'ctrl + right' in vscode.
True, but nothing is simpler than an arrow key.
W is as simple as an arrow key.
But switching between input mode and text mode is not (for me, at least, as an untrained user)
I deeply appreciate the automation vim & co. offer, but many people, like me, simply have no interest in climbing up the learning curve for editors.
That’s a great point, but learning arrow key function varies based on the app I use. So if I have to learn arrow to move around indents, I may as well learn the command to move between words.
I struggle with trying to get others to change their files because a particular program I like and use a lot handles their file a certain way. This reminds me of the olden days of the old Microsoft way where the solution seemed to be around making every app respond in the way way so it was possible to guarantee what arrow does across all apps.
But that way lost and now files are used in all sorts of weird wonderful ways.
This is not really true; ‘w’ is one row up from the home row and is easily accessible with the middle or ring finger. An arrow key is a hand-shift or an awkward pinky stretch away. Vim keybindings were explicitly designed to be simpler than arrow keys once you’ve gotten over the learning curve.
Unfortunately vim is not very useful for coding and debugging iOS apps. Or Android, or Windows for that matter.
I haven't done any iOS development, so perhaps I'm expecting too much; but surely there is an IDE that has a vim-mode plugin? Every IDE/editor I've used—all JetBrains products, Atom, Visual Studio, Eclipse...—has a vim plugin readily available. They're rarely perfect (they tend to behave weirdly with IDE autocompletion and the like), but they're more than adequate for basic text navigation.
> but they're more than adequate for basic text navigation
I really think basic text navigation is no longer a problem since the the adoption of PC keyboards in the 1980s and 1990s. Key arrows are easy to find blindly except maybe on some screwed up laptop designs.
Perhaps our definitions of "basic text navigation" are different. I'd include capabilities such as "jump six words to the right, based on natural word boundaries" and "jump six words to the right, based on whitespace only". Oh, and "jump to the end of this statement that's enclosed by parentheses".
Not trying to start a vim-vs-whatever war here, though I suppose that's inevitable in a discussion of tabs-vs-spaces...
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.
Atom handles this correctly, but it's the only editor that does, so I agree - tabs are better.
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.
Do you actually use 8 space indents??
Of course; I am a decent person. Let me just quote Linus Torvalds here:
> 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.
I cannot suggest enough to avoid this debate and pass to elastic tabstops
http://nickgravgaard.com/elastic-tabstops/
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.
Why is this dead? It provides a commentary on the feature linked.
Would love to see a vscode plugin
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."</i>
https://github.com/torvalds/linux/blob/master/Documentation/...
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.
> however, it cannot be customized in the detail that I would like
That's the whole point. Why is what you want better than what the formatter says?
I don't mean customized by an individual user, I mean customized by the team to fit their style guidelines.
"it cannot be customized in the detail that I would like"
Many people consider this a feature, not a bug.
This is a decent argument but calling it "the real reason" takes away from it.
Yes, it's pretty obvious that Tab is correct since it has semantic meaning (tab = indent), is one character and has configurable width.
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.
Exactly. Maybe a browser extension to pretty-print spaces to tabs, or sites like Github/SO can offer a built-in option.
I'd go even farther than that. Prefer {}, BEGIN/END or indented code? Prefer && and || or AND and OR? Prefer infix a+b+c or LISP style +(a,b,c)?
Pick one and the editor will show and edit code that way. The underlying code files remain unchanged.
Wouldn't LISP style be (+ a b c) though?
You may be right. I don't actually know LISP.
Absolutely.
Not just tabs vs spaces, but also camel case vs underscore, line length, etc.
Talking of which, here’s the little-used CSS rule tab-size: https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size
I totally agree, as a dyslexic big pieces of text look like a garbled mess. I need > 2 spaces to be able to navigate a file with code with any speed.
Tabs for indentation, spaces for alignment looks to me like the best of both worlds.
The problem I have (also a dyslexic) with tabs vs spaces is you cant (normaly) see tabs.
The old school 80 column fixed layouts like Fortran had did have its advantages.
> The problem I have (also a dyslexic) with tabs vs spaces is you cant (normaly) see tabs.
There is probably no editor program in your computer right now that is not able to display tabs visually.
Yes I know but I am not working with with those fugly show white space settings turned on.
Like one of the previous commentators I am a dyslexic and I find displayed tabs CR etc very visually distracting
VSCode doesn't display the CR and with the boundary setting doesn't show whitespace when it's a single space between words.
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.
More than one consecutive space is very frequently used for alignment. Converting on open and save would be simple otherwise.
The author calls for more websites to support adjusting tab widths. What editor doesn't?
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.
Nobody talks about the fact that git can convert tabs to spaces and vice-versa on the fly so the whole discussion is irrelevant :-)
https://stackoverflow.com/a/2316728
>one of them uses tab-width 1 because he uses such a gigantic font-size
But if they use a "giganting font-size" to see the letters, spaces would still be proportionally gigantic. Why would they need to have custom indent size, since everything will play along with their font-size choice?
That is, why someone might want to use gigantic fonts but constraint that gigantic-ness to the actual letters, and not the indents too? Isn't it equally important to see indentation clearly?
I'm guessing when your fonts are sufficiently gigantic indents of 1 char are more than enough to see the indentation clearly (try it out). Actually, less than 1 char might be good enough or even better.
I don't know how bad the eyesight of the mentioned person was, but you may not be thinking gigantic enough. I know of people who zoom into the text to the level where maybe two-three words are visible in a line. (not all the time, but at the extreme, when reading something specific) By injecting more indent, you have to scroll a lot horizontally, or potentially miss an extra word from view if you get 2-3 extra levels of indent. If your space is at a few cm wide, it may be enough indication. Then, there are also ways of colouring indents for better visibility. (not sure if that's used for accessibility though, but it does make large indents not as important for me)
Why challenge someone's self-selected, battle-won access solutions before you spend time with them understanding their choices?
For me the challenge is part of understanding choices. I don’t think of challenge as conflict, but as a way of looking at different possibilities to learn more about why.
There are many ways to pose a challenge.
> I don’t think of challenge as conflict
Agree, but I like to think of it as retrofixing your reasoning for the different view: "You tell me A, but I used to believe B because of C, D, etc. Can we investigate whether my reasoning was lacking, those are also in conflict with A, A and B are not actually in conflict, or B has a validity not influenced by A"
I like this symbolic way of putting it. I struggle with communicating that in a way that is non-threatening to people who are sensitive or defensive of their supporting beliefs E,F, etc for why A.
Because "self-selected" can be far from optimal -- lots of people self-select solutions and even insist they "work for them" that are not only sub-optimal but even medically or otherwise detrimental for them.
M-X tabify had two benefits. Firstly it more than halved assembly source paper tape. And secondly atleast Olivetti Teletype interpreted a TAB as a silent jump, instead of 8 bang-bang-bangs of empty spaces.
That's the kind of practical real life inclusivity that I think should be pushed instead of the "being offended by theoretical straw men" code of conduct nonsense.
But I won't hold my breath.
Surely version control solved this issue. Use whatever you like. Have a standard for the repository itself. Auto-convert if and when necessary.
It's always fun pasting tab-indented code into the MySQL client...
Then fix the mysql client...
Most decent editors can operate with tabs or spaces functioning identically, so this is mostly a moot point. With that in mind, spaces are easier to display in tools that don't handle tabs well, so using spaces is still the right approach in my estimation.
And yet these visually impaired people apparently pleaded with the OP not to take away their tabs.
Almost every program to edit text has a tab stop setting, but only the most advanced dev tools allow you the same control over spaces. Anecdotally, I’ve been struggling to get emacs to indent a certain language correctly for me (I want it to use two spaces in a place where it only uses one, I’m not really an emacs person so figuring out how to fix it is too much effort for me), if I were to switch to tabs, that would be easy: just set the tab width and be done with it. I don’t have any experience with screen readers, but it would seem to me that they should have an easier time with tabs too.
I wish the story had described the editors used by the two visually impaired coders. It seems odd that they are using an environment that doesn’t up/down convert easily. It mentioned they were forced to do this like it was a manual process.
Free IDEs like VScode do this, and it works with screen readers. Although from the description of their screens with large fonts and wide resolutions, I don’t think they were using screen readers.
Since the article is missing this bit, I can’t help that fear that all three would have benefited from knowing how to config editors to get around this problem.
No IDE I know of can reliably convert spaces to tabs in a display mode only (= without actually causing code changes).
Also, not every space necessarily should be converted to tabs, especially if you follow the “tabs for indentation, spaces for alignment” mentality: you will want everything up to the indentation level converted but not everything after. I’m sure some editors can do this, but many also definitely can’t. Tabs just work, everywhere.
This seems like something that could be resolved with a couple of git hooks:
post-merge: Reformat code based on local developer preference. pre-commit: (1) Reformat code back to repository standard. (2) Revert changes that are solely whitespace-related.
I'm not aware of a tool that would do the last step automatically, but it doesn't seem like it would be too hard to implement. And perhaps (I haven't checked) git has a built-in config option to alter how it behaves for whitespace-only changes?
There is no need to convert though. Vim for instance can work with spaces as if they were tabs.
I’ve had success with vscode converting spaces to tabs and vice versa between open and save. Knock on wood, I haven’t had it bungle any code.
I do this because some projects like tabs, some like 2 spaces, some like 4 spaces and I like coding in a particular way that’s independent of the particular projects.
I hope this is the seed to stop spaces nonsense..
Tabs v spaces should be an argument that we are long past by now, our editors no longer bound by the limits that once fueled such arguments.
Your editor should automatically purge all whitespace and format according to your settings and language canonical form. Whether tabs, spaces, curly braces on the end of line or next line, and on and on.
Go coming with go fmt is one of the great things about the language because instantly so many color of the shed arguments were vanquished.
[redacting]
Eyes don't get worse from use.
If you strain your eyes because of the lighting conditons, your eyes get fatigued but it has no detrimental long time effects.
Thank you, I seem to be severely misinformed. Redacting my original thoughts now.
I have very poor vision and have been told by two different optomotrists that for me, personally, my vision will worsen as I strain my eyes. I never thought to wonder if this was different for anyone else -- One of those things it seems.
I do not have eye strain.
I have astigmatism - something that is heredity. I use tabs.
My spherical power is normal.
Are you saying anyone without perfect vision should quit coding ?
Not at all.
I was careful with my phrasing to indicate that but perhaps missed the main thought -- Perhaps a visual tool isn't the most effective nor pleasurable one for a severely visually impaired individual. Not because of any "burden" they create on others (e.g. using tabs which isn't a real burden at all) or an elitist attitude (e.g. they shouldn't code), but because of the burden I imagine sight is to them.
I wear glasses over my contacts simultaneously to work at a screen effectively -- I've been told by my optomotrists that work at the screen will continue to make my vision worse, but evidently I'm not too familiar with the correct terminology for my own impairments nor for others (and whether they always worsen). A fundamental misunderstanding on my part.
Are you over or under 30 ?
Normally vision stabilizes at 20-30 of age.
computer work normally does not lead to blindness, I have spoken to a large number of different eye doctors and specialists about it.
Computer work may lead to eye strain but it hasn't shown to have any long term detrimental effect.
25. Yes, I'm finding this very interesting -- I'll have to ask my eye doctor what they meant exactly next time I see them.
Who said it's a "strain"?
Difficulty to see (e.g. because of shortsightedness) != "strain further", especially if that implies that their vision would get worse because of that.
Spaces are for people who understand addition. Tabs are for people who understand multiplication. ;-)
There is no debate... every rational person knows tabs are better.
\t saves bytes compared to n*' '. there is literally no other reason to do this. for 'style' both can be implemented to do the same and most editors these days can replace one with the other and have configurable tabs, or 'use spaces instead of tabs' options. in reality, if for example you sent a lot of documents over the wire, or store a lot of documents on disk, using /t compared to spaces can save a lot of bytes on disk or network... (looking at the uncompressed case...)