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
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.
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!
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?
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.
The only exception is Lisp...because it's lisp.
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.
Pressing tab in here doesn't give me an indent but changes focus.
But spaces always work
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.)
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.
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.
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.
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
Well, at least the author's honest about this being a religious argument, I guess
Depending on style in can be both.
def something(with aligned,
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:
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:
» while True:
» » print ("Hello",
» » "World")
» while True:
» » print(
» » » "Hello",
» » » "World"
» » )
(Whether visual alignment of this sort is desirable is a different question. If you want it then spaces are appropriate.)
PEP8 was only meant as a style guide for the python standard library. Although many have unfortunately taken it as a religious text.
And in Haskell. And in Nim. And in Haml. And in Sass. And in YAML.
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.
"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)
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.
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.
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.
What language are you using where 3-spaces-wide tabs are more comfortable?
I do suspect that Fitt's Law 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.
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 see more point in making this tooling easier to use and more accessible.
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.
I know the Linux kernel has an 8 spaces requirement. Code has been known to be rejected based on this violation.
Of note are Go and a few others, Go because it generally uses gofmt, which uses tabs, as far as I understand.
Golang also mandates tabs I think
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.
Not trying to start a vim-vs-whatever war here, though I suppose that's inevitable in a discussion of tabs-vs-spaces...
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.
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.
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.
> 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 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.
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.
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."
Many people consider this a feature, not a bug.
That's the whole point. Why is what you want better than what the formatter says?
Pick one and the editor will show and edit code that way. The underlying code files remain unchanged.
Not just tabs vs spaces, but also camel case vs underscore, line length, etc.
Tabs for indentation, spaces for alignment looks to me like the best of both worlds.
The old school 80 column fixed layouts like Fortran had did have its advantages.
There is probably no editor program in your computer right now that is not able to display tabs visually.
Like one of the previous commentators I am a dyslexic and I find displayed tabs CR etc very visually distracting
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.
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.
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.
The author calls for more websites to support adjusting tab widths. What editor doesn't?
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 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?
But in light of this argument, yes, lets move to tabs instead. More control for the user in how you actually display them.
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 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"
But I won't hold my breath.
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.
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.
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 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.
Quit using the minority to represent the majority!
> Quit using the minority to represent the majority!
Where did I do that, exactly? In my interaction with you, I didn't even say whether or not I agree with TFA, I only asked if its a non-issue because 1) you're not affected and 2) people have argued about it for a long time. Yes, yes, my questions were loaded and probably assumed too much, but given the tone of your comment (calling it the stupidest reason, even though its clearly a very valid concern for the people affected), I feel I was justified in doing so.
So, let me ask you two different questions then:
1. Do you agree that one should use tabs over spaces if there are visually impaired people on your team, who have difficulty with spaces?
2. Given that you can't know who may have to touch your code in the future, why do you think that its not worth doing so preemptively?
Obviously, a valid answer to 2. is "no, because the likelihood that it will matter is low", which is true, but given that the cost of using tabs over spaces is super low, but the cost of using spaces for those it affects is high (sure, you can convert, but see elsewhere in these comments, its not perfect), I feel like its an easy choice. Obviously you disagree, which is fine and not the reason I'm arguing with you.
If you strain your eyes because of the lighting conditons, your eyes get fatigued but it has no detrimental long time effects.
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.
Difficulty to see (e.g. because of shortsightedness) != "strain further", especially if that implies that their vision would get worse because of that.
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 ?
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.
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.