Last month there was a reddit discussion that outlined some really compelling accessibility-related reasons to use tabs, worth a read: https://www.reddit.com/r/javascript/comments/c8drjo/nobody_t...
But I just hate using them.
Maybe it was the 8 space default of vim (nano?) when I was sysadmining. Maybe it was that there was inertia, and tabs are always the thing that's causing problems. But I just can't get over it. I just don't like tabs.
For me, I think it's from my underlying interest in being good at something without having to make compromises or handicaps. As a benign example, I rarely/almost never change the keybinds in any of the code editors that i've used because I like the idea of being able to competently use all of them in their default settings to have a consistent experience everywhere. This allows me to use another instance of VSCode/PyCharm/Eclipse/etc. that's not my own and be able to reasonably be productive in that instance. It's a little silly, but it's something that I like.
Tabs runs counter to that underlying interest to a very small degree. They're there to be customized, and there's an expectation that you are supposed to customize their appearance for each view that you use to view them if you want a consistent appearance.
To an extent, I view the debate between the two as something similar to the debate between configuration vs convention. Convention is great when you're working within the 99% of the use cases that it supports, but it becomes difficult for the folks who need to do something not supported by the built in conventions and vice versa. Some people like one, some people like the other as a matter of preference. However, there's a small subset of the population that basically need configuration for one reason or another to operate. Whether it's because you're building a product that needs a feature that the framework doesn't support to stay afloat, or in this case, they need to be able to customize the appearance of code on the screen easily to be able to perform their duties in a reasonable time. I don't know if this comparison makes sense or is reasonable.
I will say that i've ran into enough errors due to people entering tabs into places that they shouldn't that my hate for tabs has grown more than it should. This ranges from people somehow (via copy+paste or whatever) entering a tab into a form field that doesn't allow for it to other engineers doing something similar for code and causing weird issues.
Edit: formatting
In any case, improvements with code editors have helped a lot to paper over the differences.
What I really wish is that we had better ways to express indentation or alignment than just these two. Or to associate inline commentary with code other than by using either spaces or tabs to fake a two-column layout. Separating content from presentation, including affordances for the visually impaired, is practically a solved problem for other kinds of text. Why not adopt some of those same techniques for the text we work with every day?
Develop how you want to develop and commit how your codebase is written. How is that hard? I guarantee whatever IDE you use has a feature to convert/change the indendation model of a file. Why is this even a topic?
You're not going to guilt me into using spaces because two people who read my code didn't like it. If you're using tab-width 8 I'm probably not going to like reading your code very much either. Does that mean you should change your entire workflow to suit me?
That's why spaces are better. There's no "all you have to do." There's nothing. Just use spaces. Your code will look fine everywhere. Done.
Separation of content and presentation is a fine principle for many things, but as long as we're coding using text files, we are already far removed from that world. May as well stay simple and embrace the literal characters.
...or nowhere, depending on who is reading.
Much more likely is that companies that pay more, for whatever reason, insist on spaces rather than tabs as a required coding style.
A quick Google search reveals spaces are used rather than tabs by Google, Twitter, Mozilla, Facebook, Microsoft, Apple... so that already seems fairly suggestive as the cause to me.
But I don't think the average Python dev makes more than the average go dev.
Speak for yourself- I use tabs with every language
Some systems say a tab is 8 spaces, others say it's 4. Some editors can set a tab to any customizable N spaces. But a space is always a space so your code will look like you intended (or should I say indented) it no matter who's looking at it.
Sure, IDE's are easy (though many people use multiple IDE's and/or editors across multiple machines).
I've also got a couple diff tools, a few VCS's, also the online parts of VCS like web-based pull request review UI's.
Tabs also tend not to play as nice with vertically aligned elements, if you prefer that for things like say the '.' on multi-line chained method calls, or longer function parameter lists.
Tabs for line indentation, spaces for every other kind of alignment is one philosophy. It's the one that seems to hit the sweet spot for most of the issues that I care about (cross-editor consistent yet flexible management of line indentation depth as controlled by hits of the tab key + tabstop setting).
But if you're running the project and decide spaces are The One True Way™, I'll figure out a way to get the editor to do it for me and ask you for a raise for the trouble (and, of course, market standards). ;)
You don't have to "figure out" anything. It's the default of every IDE I've ever used.
I press tab, VSCode inserts 4 spaces. I press shift+tab, it deletes 4 spaces.
Nobody actually presses spacebar 4 times to indent unless they are forced to use vim on some remote machine.
Which is probably not every IDE or editor.
> I press shift+tab, it deletes 4 spaces.
How entirely intuitive and not-awkward compared to hitting delete.
> they are forced to use vim on some remote machine.
Vim is not exactly unpopular as an editor of choice.
But overarching all that -- the ;) at the end of my comment should have been a clue that I was not sincerely arguing that figuring out how to use spaces for tabs is an involved task. Even somebody using vim (whether forced or by choice) should know `:set expandtab`. Most editors worth investing in will provide a convenient way of doing this.
Rarer are the editors that will also let you change indentation width on the fly while expanding tabs to spaces, though, which is generally easy if you use tab characters for indentation. I'm not super familiar with VSCode, but having just fired it up and tried it out, maybe it can do this if you turn on Detect Indentation, though it doesn't seem to be the default, and I haven't put it through the paces for less trivial cases.
My PhD advisor does... His preferred editor is vi (not vim, but vi)
Totally, hazard pay factor. ;)
..but I do it because of habits learned in python shell and also because of that cowboy character on the Simpsons cartoon that called himself OCD about the number 4 and then counted 1,2,3,4 tapping his foot and shooting his gun into the air.
Even then, you can just use >> and << in vim; as long as it's set up correctly it'll insert spaces.
Works with whole sections in visual mode too ("v, down, down, down, >" will indent four lines).
:set expandtab
https://medium.com/@hoffa/400-000-github-repositories-1-bill...
So the number of people that prefer spaces far outweighs the tabbers.
Now, take the pool of people that use spaces and tabs and let them compete for a 100k job. 9 times out of 10 even if randomly hired it will be a space person.
Also, as a by the way, on the medium post. The reason Java has so much tabs is specifically due to the default Eclipse formatting that prefers a mix Tab/Space approach. Which is absolutely horrifying in my personal opinion. I don't have any numbers but Eclipse probably holds 80%, followed by Netbeans and/or IntelliJ. (both of which default to spaces)
But you'll get the same result when they compete for a job that pays poorly. If all other factors were equal, the distribution of developers who prefer tabs should match that of developers who prefer spaces.
By your argument, people named Steve would make less money, because they're outnumbered by people not named Steve.
So yes, people named Steve would make less money (though this argument might not work as well for people named Jeff, Warren or Bill I guess).
Edit - ahh, hencq has a reasonable explanation for that.
Err, is the distribution is only affected by the number in each category (and not e.g. tab/space preference), then you'd be able to sample the same results for 30k jobs. 9 times out of ten it will be a space person there too.
Thus, if the 28,657 survey respondents are also randomly distributed, the ratio of poor vs good paid would be the same as real life, as would be the ratio of tabs vs spaces.
In other words, one wouldn't expect a skew in one category in favor of the other (if the choice wasn't a factor). Of course correlation != causation, but correlation can point to causation, or to a third, unknown factor that correlates with both attributes.
Tabs are great if you work by yourself. If you work with others, you need more complicated rules to be followed like "tabs for indentation, spaces for alignment."
So...
My theory is that coders using spaces have worked in more places and/or larger places, which tend to end up paying more.
Except you don't, because you could just never align code, which completely eliminates the problem. I find that aligning code is way more trouble than it's worth.
I suspect a lot of folks who work on large, multi-dev projects feel the same way. We prefer to lay out our code and indentations with the expectation of consistency for others. Spaces allow us to not worry "Will this be readable by colleagues who prefer 2-wide tabs vs. 4-wide tabs?" We just adopt a convention (2 or 4 spaces) for each codebase and run with it.
Similarly, when others have used spaces, it's one less thing to worry about when starting work on a new codebase. There's no evaluating "will this codebase look better with 2-wide or 4-wide tabs?" or "Can I override the default tab width with my preference, or will that make this codebase less readable?"
I don't get it. It allows you to not worry about it by letting you just say "no, it won't be readable by you because we arbitrarily decided to make your life difficult".
Tabs are the one that let you not worry about whether people who prefer a different tab width will find the code readable because they can configure a different tab width.
It also limits what developers can do to align things in JavaScript, Lisp, Ruby, C#, etc. -- especially when using complex call chains/lambdas, large literal data objects, s-expressions, long parallel repetitions blocks of code, etc. In those cases, using spaces is a huge benefit, because it provides a way to scoot things left or right to make them more readable. With tabs, you can't do that unless you mix tabs and spaces -- which is not cool at all.
My team uses two spaces as convention. It sucks. Nothing is readable. Whatever formatting issues would sneak in if different developers used different tab sizes would be minor compared to having to consistently read code with a quarter of your preferred indent size.
Most formatting tools should also be able to catch such errors.
Edit: It's also kind of funny how people in this thread are making it seem like there's some kind of controversy. There isn't: the question was settled a long time ago.
Tabs do not interact well with teams.
Spaces are a source of consistency for teams.
Basically, spaces have the same indentation for everyone sharing code while tabs do not.
To set up spaces only in your editor requires a mindful effort.
if(cond) {
flag = true;
} else {
flag = false;
}
flag = false;
if(cond) {
flag = true;
}
I just feel like I'm stuck in molasses, having to go through several extra steps whenever I'm writing code that compels the use of spaces over tabs. That said: It's a personal preference and I'll use spaces where appropriate.
Most people's argument against tabs seems to have to do with vertically aligning code. This is a shit argument, because tabs should be used for indentation only. If your indentation is the proper number of levels then spaces can be used for any remaining vertical alignment. Tabs should be used for indentation, not vertical alignment.
Example:
tabtabtabtabType myArray[] = {
tabtabtabtabtab 123, 456, 789, 101112,
tabtabtabtabtab131415, 161718, 192021, 222324
tabtabtabtab};
Newer editors like VSCode handle this correctly. Tab = add 4 spaces, delete = remove 4 spaces.
But really, you should get in the habit of using tab to indent, and shift+tab to deindent (not delete). shift+tab has the added advantage of being able to deintent an entire highlighted block of code in virtually all editors.
> can often be represented as just:
Well, in this case you could just do `flag = cond` but I see your point
> Most people's argument against tabs seems to have to do with vertically aligning code. This is a shit argument, because tabs should be used for indentation only. If your indentation is the proper number of levels then spaces can be used for any remaining vertical alignment.
Well, a lot of people haven't configured their editors to visually see whitespace, and since it is invisible by default, it means a lot of code with mixed whitespace is committed which is a hard problem to solve. So you just configure your auto-formatter to convert everything to spaces so there is no ambiguity.
I used to only press backspace once to delete four spaces because I use a better editor. Now I press it zero times because I've integrated black, gofmt and prettier.js into my editor and it indents automatically.
My personal graphologist said that although tabbers earn more, they tend to be more focused on their work and less altruistic, so they answer less surveys.
Sampling bias is difficult to avoid in the best designed research.
James L. Peterson, James R. Bitner, and John H. Howard, ``On the Selection of Optimal Tab Settings'', Communications of the ACM, Volume 21, Number 12, (December 1978), pages 1004-1007.
Also, max line width should be 120 characters. 80 is too limiting if you're using sensible variable names like you should.
I will have trouble controlling my frustration if I ever have to work on a codebase built with 3 spaces per indentation.
I technically press the tab button but my edit inserts 4 spaces.
So people sticking with tabs are more typically "old-school" and stubborn in all their approaches. And that can explain the pay difference.
Spaces may or may not be rendered to a specific width in different editors, and in fixed width editors are equivalent to 'pixel perfect' rendering; the difference between a dead tree rendering that is static and an electronic metadata included document.
Does the war is about pressing tab button vs space button?
Or is it about the underlying of it?
Afaik when We press the tab button the editor is sending a space right? Then what's with the fuss?
Maybe the team aspect made a difference, or devs worked at companies with strict style guidelines, which happened to be companies who pay well, or because that company is on their resume, they make more later on?
Question for all of you tabs people...do you guys think that spacers are hitting the space bar 2/4/8/X times?
some.method(param,
param2,
param3)
If a default install of an IDE (including vIM) will screw up your code.... you might consider rethinking your strategy. :-)
You should format it like this (regardless of whether you use tabs or spaces):
some.method(
param,
param2,
param3
)Tab proponents suggest alignment to be done with spaces, and indentation to be done with tabs.
some.method(
param, param2, param3)
Is it really a subject?
And I'm not saying that code aesthetics doesn't matter, I tend to obsess over good typography and alignment, but I use both tabs and spaces, switching depending on the code-base/context, without even thinking about it.
It's probably related to the editor choices one makes? As a tabs-only person, i am probably a little more autistic, a little less social (spaces are easier to share with others), a little less open to new technologies.
> 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.
> In short, 8-char indents make things easier to read, and have the added benefit of warning you when you're nesting your functions too deep. Heed that warning.