Developers Who Use Spaces Make More Money Than Those Who Use Tabs
Do you use tabs or spaces for code indentation?
This is a bit of a “holy war” among software developers; one that’s been the subject of many debates and in-jokes. I use spaces, but I never thought it was particularly important. But today we’re releasing the raw data behind the Stack Overflow 2017 Developer Survey, and some analysis suggests this choice matters more than I expected.
Spaces make more money than tabs
There were 28,657 survey respondents who provided an answer to tabs versus spaces and who considered themselves a professional developer (as opposed to a student or former programmer). Within this group, 40.7% use tabs and 41.8% use spaces (with 17.5% using both). Of them, 12,426 also provided their salary.
Analyzing the data leads us to an interesting conclusion. Coders who use spaces for indentation make more money than ones who use tabs, even if they have the same amount of experience:
Indeed, the median developer who uses spaces had a salary of $59,140, while the median tabs developer had a salary of $43,750. (Note that all the results were converted into US dollars from each respondent’s currency). Developers who responded “Both” were generally indistinguishable from ones who answered “Tabs”: I’ll leave them out of many of the remaining analyses.
This is an amusing result, but of course it’s not conclusive by itself. When I first discovered this effect, I assumed that it was confounded by a factor such as country or programming language. For example, it’s conceivable that developers in low GDP-per-capita countries could be more likely to use tabs, and therefore such developers tend to have lower salaries on average.
We could examine this by considering whether the effect occurs within each country, for several of the countries that had the most survey respondents.
The effect is smaller in Europe and especially large in India, but it does appear within each country, suggesting this isn’t the sole confounding factor.
As another hypothesis, we know that different types of developers often use different indentation (e.g. with DevOps developers more likely to use spaces and mobile developers more likely to use tabs), often because they use different editors and languages. The Developer Survey asked both about what programming languages each respondent uses (Python, Javascript, etc) and what “type” of developer they are (web developer, embedded developer, etc).
Did we see the same tabs/spaces gap within each of these groups?
Yes, the effect existed within every subgroup of developers. (This gave a similar result even when filtering for developers only in a specific country, or for ones with a specific range of experience). Note that respondents could select multiple languages, so each of these groups are overlapping to some degree.
I did several other visual examinations of possible confounding factors (such as level of education or company size), and found basically the same results: spaces beat tabs within every group. Now that the raw data is available, I encourage other statisticians to check other confounders themselves.
Estimating the effect
If we control for all of the factors that we suspect could affect salary, how much effect does the choice of tabs/spaces have?
To answer this, I fit a linear regression, predicting salary based on the following factors.
- Tabs vs spaces
- Country
- Years of programming experience
- Developer type and language (for the 49 responses with at least 200 “yes” answers)
- Level of formal education (e.g. bachelor’s, master’s, doctorate)
- Whether they contribute to open source
- Whether they program as a hobby
- Company size
The model estimated that using spaces instead of tabs is associated with an 8.6% higher salary (confidence interval (6%, 10.4%), p-value < 10^-10). (By predicting the logarithm of the salary, we were able to estimate the % change each factor contributed to a salary rather than the dollar amount). Put another way, using spaces instead of tabs is associated with as high a salary difference as an extra 2.4 years of experience.
Conclusion
So… this is certainly a surprising result, one that I didn’t expect to find when I started exploring the data. And it is impressively robust even when controlling for many confounding factors. As an exercise I tried controlling for many other confounding factors within the survey data beyond those mentioned here, but it was difficult to make the effect shrink and basically impossible to make it disappear.
Correlation is not causation, and we can never be sure that we’ve controlled for all the confounding factors present in a dataset, or indeed that the confounders were measured in the survey at all. If you’re a data scientist, statistician, or analyst, I encourage you to download the raw survey data and examine it for yourself. You can find the code behind this blog post here if you’d like to reproduce the analysis. In any case we’d be interested in hearing hypotheses about this relationship.
Though for the sake of my own salary, I’m sticking with spaces for now.
1,236 Comments
That is quite an interesting result. The fact that it is found in every language is impressive. As a tab user, I don’t think switching to spaces will have an effect on my salary or job prospects as I think the confounding variable here is probably coder personality and attention to detail. Did you look at age?
“I think the confounding variable here is probably coder personality and attention to detail.”
^^^ This.
And also: experience with source control and collaboration.
Interestingly, the author claims that experience is considered to be a confounding variable. Can you gain experience, yet, as a lone programmer? Perhaps, so this is a great point about collaboration. It’s usually when you collaborate you find out that your tab-settings are incompatible with other people’s settings, because they either use spaces, or a different indentation settings for tabs.
I’ll be switching to spaces immediately
As another hypothesis, we know that different types of developers often use different indentation (e.g. with DevOps developers more likely to use spaces and mobile developers more likely to use tabs), often because they use different editors and languages.
So… this is certainly a surprising result, one that I didn’t expect to find when I started exploring the data. And it is impressively robust even when controlling for many confounding factors. As an exercise I tried controlling for many other confounding factors within the survey data beyond those mentioned here, but it was difficult to make the effect shrink and basically impossible to make it disappear.
I’ve certainly never been asked if I use tabs or spaces during an interview. Or after I was hired. Or really in any context other than the online holy war…
I think it’s more likely that spaces are just more prevalent in a certain type of commercial environment that also happens to pay higher salaries.
This was my initial though as well.
This is certainly true for an automotive industry, where spaces are required by static analysis tools. And the automotive industry offers typically better paid job, at least here, in Germany.
@Bartek, did you notice that in Germany the difference is actually the loweset. Also interesting.
that. no question in my mind that’s the case.
who makes more money is ALWAYS about selective groups.
That’s the exact point! Thank you.
Did anyone check the company pay scale v documented coding styles?
Anecdotally, larger and/or older companies are more likely to have a documented and enforced coding style, and most of those I’ve seen use spaces. They do this for the obvious reason of consistency (ie: lack of flexibility and variation) which tends to be more important in such places.
I think it’s interesting in that personal preference (or so I’ve seen) tends to be tabs. In situations where the coder is considerably less concerned with other coders (ie: self-centered).
I’m wiling to bet (not a lot, though) that those who have changed from one to the other have changed between those environments.
Get high paying job at “BigCo”, switch to spaces and drink kool-aid™. Join a small start-up or do your own coding, switch to tabs and drink too much espresso (“office” being a cafe).
Just a thought (and possibly not a good one) based 45 years of ops & dev.
Surely, it takes more time to add 3 spaces than a tab, which would suggest the productivity of a ‘spacer’ would be less than a ‘tabber’?
All modern editors support automatic insertion of spaces when pressing tab and deleting tab-length runs of spaces with backspace.
Also, who uses 3 spaces??? Usually indentation is either 2 or 4 spaces.
3 spaces more than the first keystroke of tab or space.
I use 2 spaces with C-style languages, but 3 with XAML and HTML because with 2 spaces leading angle brackets kinda line up in a smooth line, and it makes it harder to make out separate lines; and 4 spaces take up too much place especially considering how reliant those languages are on nesting.
@sullivan modern editors make spaces instead of tabs, but also…
Using spaces to align code, especially when declaring class properties, JSON objects, etc. makes code SO much easier to read and debug, it surpasses by orders of magnitude the time it takes to write said code (there are also an ample number of plugins to help align by =, :, etc.
^ this. My code looks beautiful and spaces help. Although with eslint being the current necessary fad, I am losing ground on readability (while gaining code style consistency across my team).
It has to be the factor of age.
I know this post is 3 years old at this point.
Seniority == more money.
Spaces are probably an old habit carried over, and in my opinion not a very good habit, as it doesn’t scale. Passing code along with 4 leading spaces to a developer that uses 3 leading spaces or someone who uses tabs, is bad code. With tabs, by default you have more legible white-space, rather than needing to delve into the settings of your code editor and seeing if you can format the leading spaces’ indentations.
I think this has more to do with age than the actual effect of spaces vs. tabs. Tabs are the obviously superior form of indentation and are way more efficient.
Did you look at number of languages space vs. tab users know and/or use? I’d imagine being a polygot would command a higher salary, and it’s possible space users tend to know more programming languages than tab users.
With all the different languages I work with, I use spaces because they’re consistent across all editors. Tabs are not.
When you open an editor and see a mixture of tabs and spaces, all the code can be out of whack. Tabbed spacing also wreaks havoc when the editor does code clean-up or comparison for code reviews.
Using a specific number of space characters represents consistency and intentionality, which I suspect reveals more about the personality of the person doing the work. Tabs might be faster, but they’re sloppy. You don’t know what tools your other team-mates will use five years down the road when they have to read your code.
I agree. I think using spaces instead of tabs indicates forward-thinking and caring about your fellow programmers. I can see that kind of personality being more highly valued and thus the increased salary.
I’d argue it can also be explained the other way around: with tabs, teammates can easily configure the visual tab width in most editors according to their preference. With spaces that is not easily done.
What a nonsensical argument. There are people who use 2 spaces and there are those who use 4. Put them together, what do you get? Oh yeah, same bloody issue.
I guess we need to look the other way. Developers who earn more ( are obviously Good at what they Do), Prefer spaces than Tabs. This can be inferred that better programmers prefer spaces.
> Developers who earn more (are obviously Good at what they Do).
This is a very poor deduction.
You *can* infer that, but it’s foolish. There are so many personality factors behind those two statistics! Developers who earn more ≠ better programmers; they may earn more
based on their assertiveness with raises and beginning salary alone, which has nothing to do with their programming quality.
Spaces master race!
We can do without the Nazi references thank you,
It’s actually a Zero Punctuation reference, interestingly enough.
Which was a reference to . . .
lol, it is not a Nazi reference. Know your meme.
Know your history! 😀
have a look
I could definitely do with a nazi reference. It’s called a joke/meme 🙂
Isn’t it more likely that older developers who are locked in their ways use spaces, and since they are older they are more experienced since they have been developing longer and thus make more money in general. Like in decades past you could probably say people who smoke make more money.
No. The very first chart is about years of experience.
Years of experience; Not age.
Check the x axis
Read the article – not the headline 🙂
Read the article. The very first graph plots age, and it starts out with spaces over tabs, and continues. Nothing to do with older age. Plus, a modern PHP developer who has adopted the PSR coding standards isn’t “locked in their ways”; it’s a prevalent coding standards that’s become widely-adopted.
All professionals know that you cannot write source code that contains tab symbols, because such
code will always turn into an unreadable mess whenever exported (for example when posted on SO). Therefore all professionals tend to know that you configure your text editor to insert spaces upon tab, which tends to be the default setting in almost every IDE out there. Then you can indent by pressing the spacebar or by pressing the tab key and it doesn’t matter. Assuming you know these things, the question “tabs or spaces” doesn’t even make any sense.
unless you also configure your IDE to magically delete 4 spaces on pressing backspace after an IDE inserted 4 space block, there’s serious chances of messing up the formatting of your code. This risk goes even bigger if you have junior devs working on the codebase.
How? Most editors don’t delete 4 spaces but 1 when you press backspace. You will have to be pretty damn oblivious to your own source code if you don’t notice that the marker isn’t where you want it to be. Really, this whole “tab vs spaces” is a non-issue that doesn’t exist. All professional source code out there that uses space tokens, because insert-space-upon-tab is industry standard. I have no idea why I am the only one raising this question… nobody else used a source code editor before?
I’m with you on tab’s converting to spaces 😀
Jetbrains IDE’s delete 1 space upon backspace, and depending on coding style, will insert 2 or 4 spaces upon tab.
You can then remove the indents by using shift+tab.
After selecting multiple lines you can indent / unindent as much as you like with tab. pressing space just deletes the block of code.
Maybe these anti-tab people are still using vi / notepad that keeps tabs as tabs?
The “anti-tab” people do the same thing as you (e.g., I use vim and it also can insert spaces on tab, just like most IDEs can insert “soft tabs”). We frequently press the tab key just like normal people, we just want that to map to spaces, not tabs. On the other hand, the pro-tab people use actual tabs, that is the 0x09 character, in their code.
Ah okay thanks. I prefer spaces, and will generally swap any tabs I find over to spaces.
I think there is some crossover in the discussion on this page about use of Tab key vs actual tabs in code. In general it seems fine to use the tab key, providing it maps to spaces.
“vi / notepad”? LOL, sure, those are the same thing. 😀
Most derivatives of vi (and vi itself) have shift and unshift commands which are configured separately from tab stop positions. When I hit tab in vim, the “expand tabs” setting is respected and up to 8 spaces are inserted as necessary to reach the next tab stop position. But tabs which were originally in the file are left alone; I don’t want my editor changing stuff that I didn’t explicitly tell it to change. 😉
What terrible editor is this?! Most/all editors I’ve encountered are configurable to have backspace undo one level of tab indentation, even when tabs are converted to spaces.
The last time I can remember an editor didn’t do this was ~ a decade ago.
Sublime deletes all tab spaces together by default when u have tab translation into spaces. Also *all* good editors can programmed to do nearly anything you want.
Pretty sure Vim also deletes tab spaces.
shift+tab will undo the spaces inserted with tab.
Also, don’t most IDE’s have an option to auto format code?
To auto format code is evil if you work with version control systems.
I suppose in an ideal world you could make everyone use the same editor and same auto formatting.
This sounds like a “No true Scotsman!” argument.
Not really, because “no true Scotsman” assumes that the arguments are subjective. “Professional programmer” is a level of skill acquired through experience. Everyone who is experienced have exported code and viewed it in a different editor. This is not subjective – of course every programmer will eventually end up using different editors. Upon doing so, anyone with eyes will notice that code indented with tabs turns into a horrible mess. This is not subjective, it is a simple fact, since different editors have different tab settings. Upon noticing this, people who indent by using the tab key eventually starts configuring their editors to insert spaces. Programmers who have interacted with other programmers will know from experience that this is a phase that most programmers go through as part of learning. This leaves us with 3 categories: inexperienced programmers who indent with tab key to insert tab symbols, experienced programmers who indent with tab key to insert spaces, and programmers (no matter level of experience) who indent with spacebar to insert spaces.
All professionals know that simply having different tab settings doesn’t turn code into a horrible mess. Tab settings usually just change the spacing of each indention level. Exactly the same effect they have when converting tabs to spaces.
I know multiple experienced, professional coders who know all of the above and nevertheless prefer tabs.
Heck, I believe Linus mandates tabs in the Linux kernel.
I disagree with the preference for tabs, but that doesn’t mean it’s only endorsed by the ignorant or inexperienced.
I was expecting that people who use both make much less money…
To determine the salary of people who use both, XOR the average salaries of people who use spaces with the average salaries of people who use tabs.
As someone who started with tabs and quickly switched to spaces ~15 years ago, I think it’s something much more trivial that’s often frowned upon when source control is involved, but that makes certain parts of code far more readable: Using spaces to align similar statements. It’s much harder to do consistently when tabs are involved. I can easily see that extra readability leading to a jump in productivity, though I wouldn’t expect that much.
this. however, this is the core argument in the “tab v space” holy war, and as such, it won’t convince anyone.
space argument: this
tab argument: this is irrelevant, your IDE/text editor can translate these alignment issues transparently. This isn’t 1995 anymore.
I’m in the “spaces” camp, btw
> your IDE/text editor can translate these alignment issues transparently.
Spaces always require you to use multiple arrow key presses to move through them. Tabs are a single key press. This isn’t important if you are a vim god I guess though.
Or when doing work collaboratively, the last thing you want to be doing is changing the indentation size of spaces (causes chaos with alignment cases), yet tabs let you do this visually without affecting anything else.
Just pointing out that the translation is not quite transparent. There are still differences.
ctrl/cmd+arrow makes short work of travelling through any indentation or even white space, regardless of type (though I personally find Mac deals with this in a terrible fashion).
And vim uses w (for “word”) and b (for “back”) to do the same – jump a text word and its trailing whitespace at the same time in a single keystroke.
this is why i always use spaces
I’m not talking about the beginning of the line, though. I’m talking about in the middle of the lines. For example, aligning assignments or dictionaries into columns, or a related-but-not-abstractable series of function calls or math statements, to make it far easier to just scan down.
If people could easily stick to Pluckerpluck’s tabs-for-indentation/spaces-for-alignment way of doing it there wouldn’t be much of an issue. But inevitably, tab-users will use tabs to do those alignments, and that’s when it quickly gets all out of whack.
well… idk about “IDEs” but vim can handle this use case
still, spaces are the only real way to code
I’ve been arguing for Tabs for Indentation, Spaces for Alignment for years, but.. too many people see it as an all-or-nothing approach, probably since not thinking about it means they can concentrate on other details.. or their 3D printer breaking again.
I prefer tabs for a variety of reasons, but there is ONE aspect I dislike which is aligning statements. Normally I would just say that you should use tabs for indentation, spaces for alignment. The problem is that people suck though and screw this up ALL THE TIME. If people just used tabs for indentations and spaces for alignment it would all work, but alas, that’s not the world we live in.
My solution is to newline the stuff I want to align. Took a while to get used to, but I think it’s optimum:
if (longComplexThing && otherComplexThing && finalComplexThing) {
becomes
if (
longComplexThing &&
otherComplexThing &&
finalComplexThing) {
Lets me use the glorious tabs but still ensure code compatibility with all the crazy people who can’t follow a set of coding guidelines.
I learned long ago you wouldn’t want to align with tabs, but that doesn’t mean you can’t use tabs for indentation. I suppose in the end making such a distinction is too painful when your IDE doesn’t do it and you can just hammer tab a few times to align instead.
If you use tabs for indentation and spaces for alignment, how do you handle the case where different tab widths break the alignment?
They don’t. When would you align things on different indentation levels? That’s insanity regardless of if you use tabs or spaces. Using Pluckerpluck’s example below: under TISA that would be spaces, not tabs.
I might be missing something, but how do spaces help with alignment? In my experience, it’s the complete opposite. Tabs “just work” and let me align things effortlessly. You can align with spaces, but that means you have to put ~triple the effort to insert and ~triple the effort to delete with (as far as I understand) zero payoff.
I’ve definitely had trouble inserting code with tab indentation on SE, but I’ve had *as much* trouble inserting code with space indentation. It’s just as misaligned, so I’m not sure what the deal is here either.
I’d imagine the real predominant factor here is what kind of coding styles prevail where each of those programmers work (since I’d imagine that eventually this would influence what said programmers get accustomed to using, and hence “skewing” the results here). That would also probably show up some other patterns in common rather than spaces vs tabs.
This seems like a good hypothesis. To pick on marketing firms and programmers who work for them, I would have to guess these are the low bar jobs from my experience in working in many different organizations in terms of rigor. The enforcement of structure is much more relaxed and code reviews are practically unheard of compared with a software shops that typically pay more. Code shops tend to use spaces over tabs as it tends to work better in command line editors such as vim and then look good on github as well. Try having tabs on github. It sucks.
.editorconfig in your repository root specifying your preferred indent_size for display on GitHub easily solves that.
Thanks for actually paying attention 🙂
Tabs are for word processors not IDEs
Are median salaries in Germany and UK really *half* what they are in the US? Maybe this is something I should already know, but that was the most surprising revelation here to me.
Perhaps related to the differences in income taxation?
No, Americans are more likely to lie about how much they earn. Cela explique tout.
Surveys are notorious for having people answer what they think should be the right answer.
That means that a bunch of responses will be conditioned on the fact that Richard from ‘Silicon valley’ uses one or the other (I forget which – I’m a Guilfoyle… I do things that matter, so I have no time for trivial nonsense… he said, typing a comment on the internet – in my own defense, it’s 12:30 a.m. here and I am having a glass of wine having almost finished a project report that was due a week ago).
People with nothing better to do need false dichotomies so that they can pick a side and belong. It’s been that way since the Blues vs Greens in Byzantium, and probably before. Anyone who wants to belong to either side of a pointless dichotomy needs to die in a fire.
Hm. Gross salaries for developers in the US are vastly higher than in Germany and the UK. Maybe not 2× but from the numbers on starting salaries (!) that I’ve seen, 2× actually isn’t terribly far off.
Lying about salary might be another factor but it’s minor compared to the actual, real salary difference. Of course this also differs within the US (Bay area …) but even the mean is higher.
Americans are more likely to lie.. as you sip on kool-aid calling it wine. Irony…
My salary dropped even more than that when I moved from SF to a smaller city in The Netherlands. But I had lived here before, so I already knew those numbers to be meaningless. Where before I had stress and debt, now I have more free time and no money problems. This might sound very strange to my fellow Americans, and U.S. salaries being so high might sound strange in the EU, but, as a general rule, if your U.S. salary is X, you can have a more pleasant lifestyle even with a salary of X/2 in Europe. This is because housing, healthcare, transportation, and even going out to bars are all massively cheaper here. It way more than makes up for the lower salaries.
Maybe the space users have more of a ‘i don’t care if it is theoretically correct, it works’ attitude and therefore more of them have a job in a larger company which pays better?
You’re probably a tabber!
I doubt that you are one 😉
Maybe people who use spaces are more likely to overreport their earnings, because they also overcompensate on the lack of control in their lives by repeatedly mashing the spacebar.
Do you actually think people who use spaces for indentation press the spacebar for every level indentation that they want? Because that’s not the case, you just configure your editor to use spaces for indentation, to convert tabs to spaces. So when I hit Cmd+] or Tab, it inserts or removes 4 spaces. When I go to a newline it inserts the relevant number of spaces.
then what’s the point of using spaces if you are already pressing the tab key?
PEP-8.
Worth noting that PEP-8 was never meant to be used for anything outside the Python standard library. There’s no reason to adhere to it in your own code, and there’s no technical rationale behind [many of] its recommendations.
Being consistent with every other Python project is a good enough reason for me. The tooling around it makes compliance very easy.
While I absolutely hate using whitespace rather than curly braces to denote a block of code, it is far, far outweighed by the fact that most python code looks the same since we mostly all share the same set of guidelines.
1 – You can align text with finer granularity. For instance if I place a line break in a comma delimited list, the editor can align the list vertically with the resolution of a single whitespace, not 2, 4 or 8
2 – The code looks the same no matter what the local tab size setting is
That makes no sense. Tabs are only meant for indentation; You would use spaces either way for alignment. Tabs for Indentation, Spaces for Alignment.
the point of using spaces is so that the next person who looks at your code sees it the way you intended it to be seen.
I’ve seen one programmer in this discussion who claims that do that. I can’t imagine why.
Maybe people who use spaces are not developed enough to understand humor.
Tabber!!!
Perhaps programmers using spaces lie more about their salary.
Found the old school tab user 😉
The trend is the opposite. I find it amusing when people say “Who
still uses tabs?” — Tabs are more flexible and a *proper* understanding
of them (and TISA) is only starting to emerge.
I have yet to find a single “more flexible” thing one can do with tabs that I can’t do with any code reformatting tool…
Not having to commit it. The moment you bring up a code reformatting tool, it doesn’t matter which side you’re on as the whole debate becomes moot: You pick one, and the one wielding the reformatting tool makes it happen. Period.
Ahhh…! I believe I just now understood. I never considered the firm “without code reformatting” situation, thus was always confused with all this mess.
Like… just hit two keys, and your code looks like you want. Indeed, without that, I would have to rethink about this.
ta!
Indeed, I think this whole mess revolves around not using reformatting tools and not understanding that TISA is an option… but whatever.
Certainly 🙂 I know I should be making more money 🙂
Actually I only use vim for programming, none of this newfangled IDE stuff for me. In vim it’s trivial to :set expandtab which will accept tab as input but replace it with the appropriate amount of spaces. Combined with :set smarttab you don’t notice the difference with real tabs (besides that your source is larger, which in the early days was actually a concern…).
You can use vim editing inside a lot of IDEs nowadays. Best of both worlds? Give it a shot. Newfangled things sometimes are good.
Perhaps programmers who use spaces also participate in satanic rituals
I prefer spaces, but naturally one must adapt to the the coding style used in the project, so I am fine (begrudgingly) with tabs, but what really grinds my gears is when both are mixed – this causes such a horrendous mess…
My IDE always offers to convert spaces to tabs… thus CRUELLY KEEPING MY SALARY DEPRESSED!
gofmt uses 8-char width tabs for indentation. Are the Golang devs making ~$20k more with spaces not using gofmt?
gofmt uses tabs, your editor makes them 8-char width 🙂
gofmt even standardizes the width
. . . of course you are free to change it in your editor to be whatever you want.
Oh, interesting — it even understands TISA. That’s great!
The very recent video “The Post JavaScript Apocolypse” on youtube features Douglas Crockford who says “If you can use one and do without the other, discard the other.”. We cannot do without spaces but we can do without tabs. This clear reasoning removes ambiguity and is a good practice to use this thought in code for all types of things that cause arguments but are not important. Its possible the slight nudge in one direction or the other may correlate with the small % of people that actually think this way where as it may only be a preference in the vast majority of cases as it is in mine.
I’m sure it’s a nice-sounding aphorism, but from a language design standpoint that makes *no sense*. With the same reasoning you could eliminate lots of operators and formats from languages, making the remaining operators have more (ambiguous, context-dependent) meanings. This is obviously not a desirable thing.
It’s no different with spaces vs. tabs — they have different semantic meaning, for different purposes. *Could* you use one to replace the other? Sure, but you’d lose the unambiguous semantic meaning, which is a bad thing.
This is not a good example of “unimportant”. We would all do assembly language then by your reasoning.
What are you talking about? This has absolutely nothing to do with “using low-level languages” (which I presume is what you’re referring to), it has to do with unambiguous language design. “Assembly language” doesn’t come into it.
I feel like you’re trying to have an entirely different discussion, totally unrelated to the point I’m making.
Contextually, Crockford was arguing about coding style, not about language design, specifically when it comes to tradeoffs of equal functionality that your team decides as a coding style. In that light, my assembly reference does relate to you taking an argument too far, for example if you said, we might as well only use assembly if we must reduce things to their basic functionality but instead, you used “language design” which is equally too far out of scope.
An analogy is not an argument, it’s an illustration. At no point did you actually argue how my argument was being taking “too far”, and you still haven’t done that. If you disagree with my argument, fine, but then *address the argument on its own merits*, don’t just throw in a poor analogy.
Try a sentiment analysis on your post history. You will find it enlightening.
And now you’re attacking me personally, instead of addressing my argument. If you don’t have a counterargument, then it’s fine to just refrain from responding, you know.
There’s no argument in the first place which was the point. It was about context which limits scope. However your sentiment averages toward negative which is unbiased if you use an AI. You are able to change that upward if you want to.
I’m seeing a pattern here in your responses. You are always correct from your perspective coupled with negative sentiment. Hope that works out for you.
Yes it does. You can do anything in assembler so what is the point of any other programming language? By your logic of course…
You may have just converted me.
Well we use tabs for something different than spaces, when we use it for indentation. By your argument we would all code with 3 symbols as those are the fewest symbols we would need to program.
Taken out of context. Douglas was referring to unimportant arguments about code style. If you take it in that context, your argument seems reaching.
Maybe being extravagant in your use of bytes reflects an attitude of plenty that becomes a self-fulfilling prophecy in life.
oh, so that’s what closing the line break html tag was all about…
The attitude of plenty is rampant these days.
Indeed, the median developer who uses spaces had a salary of $59,140, while the median tabs developer had a salary of $43,750. (Note that all the results were converted into US dollars from each respondent’s currency). Developers who responded “Both” were generally indistinguishable from ones who answered “Tabs”: I’ll leave them out of many of the remaining analyses.
I’m a 10x spaces engineer. Your codebase is going to have so many more spaces in it when I’m done with it. Certified spaces growth hacker.
I take it you’re a certified Whitespace developer then?
I only work with /[ ]+/g not /s+/g
all that whitespace isn’t going to print itself chris.
I think it’s funny that tabs people in the comments are saying “well it’s probably some other variable!”. The other confounding variables are exactly the point. No one actually believes that switching from tabs to spaces will gain you a nice raise. It’s the type of personality (or habits, or whatever) that lends itself to spaces that is more rewarded.
That is exactly what I suspect
Some languages have universal convention for one or the other – for example Python for spaces and Go code for tabs. So Python programmers definitely earn more than Go programmers?
but go you just use fmt…. who cares what you write go will fix it
Except the last graph shows that for both Python and Go developers, spacers earn about 33% more than tabbers.
I find this to be both hilarious and insightful. Thanks for sharing.
Yeah, developers who use space over tabs probably do make more money. Because developers who use tabs get the job done faster, and as such, work less hours!
They are ‘Whitespaces’, a useless character in most languages, and yet you waste eight key strokes on them, when you can do the same with one!
Almost every modern editor supports soft-tabs; that is, by hitting the TAB key, you insert N space characters. “Eight keystrokes” is not realistic.
Perhaps not eight, but unless N is equal to one, my point still stands.
N is equal to one
Ya, misunderstood!
No: Sublime Text can obviously insert spaces when you press tab: https://www.sublimetext.com/docs/2/indentation.html
Do you honestly think people actually hit the space multiple times? Dude.. Everyone just changes the TAB output to X spaces.
Yeah I misunderstood
No, it really doesn’t.
N *is* equal to one when using soft-tabs. That’s the whole point…
I press TAB once, the editor inserts ‘N’ spaces with N being the number of spaces needed to make the result visually the same as a hard tab. Try to grasp this concept, apparently it will make you earn more money if you do.
This is the problem with that “Silicon Valley” episode. Nobody is hitting the spacebar eight times, people just use tab but render it as spaces
ive worked with developers who use space manually… it … is horrible
I don’t see why anyone would do that
Neither did I until I saw Tyler’s answer above. I didn’t imagine anyone would have to sub-condition themselves to handle the situation…
People indenting by 8 characters instead of 4 are the real problem here, let’s be honest.
Agreed. If you’re going to do that, just go a bit further and indent that shit all the way off the edge of the screen.
Try saying “Whitespaces” is a “useless character” when coding in Whitespace – https://en.wikipedia.org/wiki/Whitespace_(programming_language)
or python.
Nobody wastes eight keystrokes for indentation. Us space users use the tab key just like you guys. Every decent code editor will do the right thing and insert the appropriate amount of spaces and/or tabs.
How are those using linebreaks :)?
I’d love to see some error bars on your bar graph. 🙂
With 12,000 respondents, the error bars are likely too small to be visible on this scale.
I’ve always been confused about something: What happens when I set my editor to output tabs as spaces?
I’ve been using Sublime for years, recently jumped to Atom and VS Code; but in all I always configure my tabs to be 2 spaces.
On what side am I? I prefer spaces for indentation. It’s more readable, less “empty space” on my screen. But I’m not a fan of smashing my space bar 2 – 6 times for each line.
You’re basically using spaces. If I change the keyboard letter A to output Z it doesn’t mean I’m using A.
That’s spaces, I don’t think a lot of people do what you say ‘smash the keyboard repeated times’
I think everyone does exactly that. I don’t know anyone that puts spaces in manually.
The only logical answer is that you are in the tabs group, because you are pressing the tab key to indent. Perhaps the survey’s next iteration should specify to respondents that “spaces” means “pressing the spacebar X number of times”, and we’ll see if this correlation stands.
I’m pretty sure no professional programmer presses “space” repeatedly. The survey was asking after the textual representation, not the key you’re pressing.
Hi, professional programmer here. Who presses space repeatedly.
You may want to revisit that 😉
“The only logical answer is that you are in the tabs group” – I completely disagree. The debate isn’t about what key you press to do indentation, it’s about what characters are in your source code.
finally… the only thing more baffling than tab users thinking space users mash the space key repeatedly, is tab users thinking tab is actually about the tab key, and not the tab character.
If your source code has tabs in it, you’re a “tabs user”. If you use the tab _key_ but have spaces in your source code, you are a “space user”.
The debate isn’t about which key you press to do indentation, it’s about what characters are actually in your source code.
always use spaces
I’ve configured my IDE to allow the tab key to use spaces. Prefer tab key for efficiency, but understand the spaces necessity. Does this data account for the ability to use the tab key to execute spaces? How would you categorize this group?
We got into a heavy debate about this at work, to the point where I made team tabs and spaces shirts. Tabs has been printed twice, Spaces none, if that’s any indication.
https://cottonbureau.com/products/team-tabs
https://cottonbureau.com/products/team-spaces
I imagine most developers in the “spaces” camp do this. I know nobody who favours hitting the space bar multiple times over hitting tab once. But this would certainly be an interesting hypothesis!
I am a dev who actually hits the spacebar 4 times (if my IDE doesn’t automatically indent for me when I hit enter to go to a new line). I avoid using tabs because it’s not much of a time saver and specifically because we are conditioned to expect “tab” to be “move to the next UI button/element/file” in any other computer context. I’d rather not have to hammer a sub-condition into my mind for “different tab behavior but only in this one IDE”.
Why? Every modern IDE can be configured for the tab key to enter the proper number of spaces. I can’t imagine having (or choosing…) to type four spaces every time I wanted to indent something. Dude, get a better editor!
His point is (if I understand correctly) that way the behaviour will be consistent even if, for whatever reason, he has to use an editor that doesn’t understand this — or even, I suppose, if you’re typing code in a text box on a web page where tab instead causes the focus to go to the next field..
Except word processing and document layout, where we expect tab to be “move to the next tab stop/indentation level”. The tab=”indent” convention is both older and more widely known than tab=”next control”.
I’m a tabs person, mostly because it’s simply the right choice. Firstly, the file size will be smaller. That has to be the preferred choice. Who would choose to have their files be larger? Secondly, it gives you total flexibility in terms of choosing how big a tab is in your editor. If you’re weird and prefer a tab to indent by 8, then that’s your choice. Those who have incredibly nested logic can use 1 or 2 characters. Personally I always choose 4. The thing is, you choose how you want to see it. If the file is using spaces, you don’t get any choice. The indentation will look the same always. If you want to ensure that people always see it the same, you simply specify in your coding standards that people should always set their indentation level in their editor to 4. I’d love to hear any real advantages to using spaces, other than the salary increase 😉
“I’d love to hear any real advantages to using spaces other than the advantage this entire blog post is about” 😉 Also good look specifying *your* coding standards to dictate that *other people* change their own settings to match your preference.
The advantage of a tab is that it allows you to choose your visible indent size. However, varying indent size makes it functionally impossible to enforce column width. Therefore if you have a coding standard with a fixed width, spaces are the appropriate choice for justification.
Why would you need to enforce a column width though? Alignment after indentation? If that’s the case then I guess the real reason there’s such a war over this is people don’t understand TISA.
By column width, I meant the total document width. (I didn’t write clearly, sorry). If a document has a 100 column max width, and one person uses two space tabs, and another uses four space tabs, and another uses eight, and they all use a 100 character width, then when one person views the work done by another, then the formatting will look wrong.
The 8-char equivalent indent will look short on the 2-char equivalent user’s screen, having randomly short line lengths. The 2-char equivalent user’s code will overflow the 100 line length limit on the 8-person view. Alignments (say, for simple ascii images) are going to be off too.
It’s going to lead to a code base that just looks wrong and messy.
I don’t think tab/spaces matters for your own code, but if you’re in an environment where many people edit the same code, then using spaces with a fixed indent makes it easier to keep the code clean looking.
What you’re saying doesn’t really make sense to me unless you’re talking about in-line alignment; Tabs (actual tabs) are only for indentation, so the width of a tab doesn’t matter. You wouldn’t align the insides (and technically leading spacing, after indentation) of ASCII art with tabs.
It wouldn’t “look wrong” anywhere. Now, yes, you can exceed a column limit but unless you set it to something insane line 10 or 20 that’s hardly an issue (unless you’re the type of person to be totally inflexible about that column limit, which will give you other issues anyway).
ummm it’s real easy to “dictate” that *other people* change their own settings to match your preference. It’s called using a static code analysis in your build process (I have our lint checker to check and error out if spaces are used in any code).
You want to use spaces in your code? Great, but your code won’t pass the build queue if you do *wink*
This assumes that you’re the person in charge of setting and enforcing coding standards for your group, and also that you’re only talking about code environments where code is shared within a small group, which are two pretty big assumptions. It’s also a pretty douche thing to do if you block spaced code.
Well wouldn’t it also be a pretty douche thing to do to block tabs? And aren’t coding standards supposed to enforce a consistent style (see: https://www.smashingmagazine.com/2012/10/why-coding-style-matters/)?
I prefer tabs (that’s just my world, but I can work with spaces if needed). But what happens when I’m walking through someone else’s code and they use spaces, but for some reason didn’t always use a 4 space indent. Their code could look messy and take longer to walk through. Or worse yet, consider the developer who doesn’t use indentation at ALL and try to walk through their code to figure out what’s going on (I’ve personally come across both style of coders, my boss falls into the latter group).
Code Standards and Coding Style DOES matter, even if it’s only you working on the code.
… stepping off my soapbox now
The main advantage as I see it is that everyone on a project seems the same code. While it should be avoided, we sometimes like to line stuff up in columns, or align multiple lines of code or data so that it’s easy to read. These alignments simply don’t survive varying tab widths. Combined with the fact that you can’t see tabs, so “foobar” may appear as “foo bar” or “foo bar”.
Perhaps the real debate is simply between people that see that as a problem, and people that don’t.
ever heard of minification? It uses the same principle as the one you’re arguing for, which is who would want a bigger file size 🙂
Got my tab key to insert 2 spaces on vim
No worries, one day you’ll understand why spaces work better when you’re working with other people, and then you’ll switch and be a better colleague, and ultimately earn more.
If you want to speed up the process, read jwz’ rant. I don’t think reading it is enough, though, it’s a really deep issue.
I still see indentation issues from time to time in other code, and every single time it’s caused by someone using tabs. Sometimes a previous version of myself.
Well, for me the ultimate solution to the problem is `go fmt`. It solves the multi-programer problem without sacrificing any principles. I wish more programming languages would supply such tools (code formatting normalization).
It seems to be more a case of “waaah this breaks my software” more than anything. TISA is the best solution.
I sincerely would like to know how spaces are better for working in a team, I’ve seen this as an argument several times but I can’t find why… I mean, how is it that you would not mess up with spaces and would with tabs? If all developers on your team are using tabs, how would spaces benefit the team or its members?
The main reason is that you quite often can’t see tabs. If you type “foobarbaz”, it may appear as “foobar baz” or “foobar baz” or something in-between, depending on your tab setting. Thus, it can be impossible to distinguish between words separated with a tab and words separated with a single space. Though, I acknowledge that some modern editors will display a symbol for a tab, which solves that problem.
There’s also the problem that, as programmers, we sometimes like to line stuff up. Due to the nature of code, lining things up with one tab setting may look awful in any other tab setting, thus making the code harder to read for some, easier for others. You can make the argument you should never attempt to neatly line up code, but there are sometimes good reasons to do so.
Can you work around all these issues with tabs, or simply live with these edge cases? Yeah, probably. The argument for spaces is that these become non-problems that don’t need to be worked around. It’s One Less Thing to worry about.
Most people I know who use tabs only use them at the beginning of the line. This allows a semantic “one level of indentation” that the reader can control how large it displays.
I don’t recommend using tabs to align things, because then you are correct, it won’t work depending on the tab size. (TBH I don’t recommend aligning things at all but that’s an entirely different story)
Yes. The correct answer is tabs for indentation, spaces for alignment, and alignment is generally to be discouraged.
The problem with spaces for indentation has exactly the same foundation as people are complaining about for tab width: one developer wants to use 2 spaces per indent level, the next wants to use 4. With spaces this problem is worse than with tabs because you can’t correct for it properly with local settings. You end up with the first indent (from dev A’s revision #1) at column 2 and the second indent (from dev B’s revision #2) at column 6.
We can certainly agree that if everyone always uses tabs consistently and everyone always uses the same editor configured in the same way, then tabs will work fine, and even allow people to use different indentation widths.
Now, the problem is that those two requirements don’t hold in practice E.g. you need to look at code made by others, and those other people need to edit your code. Once you have a mixture of tabs and spaces, the code will start looking weird for someone, not necessarily you.
My favourite example is when you look at code written by tab fans who configure their tab width to say 4 spaces. It is often the case that the code isn’t actually consistentely formatted with tabs, so with a default 8 space tab that most editors will use (or view source in the browser for that matter), it looks garbled.
I’m afraid it’s a real and annoying problem. I used to use tabs myself.
I’m aware you probably won’t believe me until you’ve experienced it yourself.
So your argument isn’t about spaces nor tabs, it’s about giving up and using spaces because then you don’t need to worry about it. I mean really, that argument could be applied anywhere where there is any sort of debate on how or what to use — package managers, specific packages, etc. … but you can standardize either way, and need to make sure people follow the standard, otherwise you’ll experience breakage no matter which debate it is.
Or am I missing something?
To be clear, I *have* experienced this, and not just in the tabs VS spaces scenario.
I’m sorry if my opening comment offended you, I was trying to be joking, but I apologize if it came across condescending.
Now, to your question: The thing is, if everyone uses only spaces or only spaces and 8-space tabs, it mostly works everywhere because all editors and viewers understand spaces (well, HTML interpreters ignore them unless in pre tag, but…) and many viewers also handle 8-space tabs okayish.
Now someone figured out that you can use tabs as a sort of system, just like when tabulating data. The benefit is it enables people to configure their favourite tab width. And some people do that, and THEN we have the problem because suddenly we have non-standard tabs so the file is going to look different to everyone else than the author and people with editors configured like the author. Worse, the code can end up being inconsistent, unnoticed, and then it can garble up completely for other people. The only way to fight that is to start being careful about the tabs.
And right there is the point where the slight benefit of tabs just isn’t worth it compared to the downsides.
You seem to think that you can standardize everyone to use tabs. You can’t. And as long as you can’t, you can’t have custom tab widths without causing trouble for other people, and if you’re going to use 8-space tabs, there really isn’t any benefit at all if you’re using an editor more advanced than notepad. And there are still downsides. My life was simpler when I decided jwz was right and I made my editor not insert 8-space tabs, navigation became much more intuitive.
Now this is an argument, mostly against inserting non-standard spacing in text that other people may have to look at. 🙂 I don’t think my previous comment was an argument, really, I was just explaining what I’ve come to see.
The fact that people don’t have the same indentation is irrelevant though, unless you’re using tabs *everywhere* on a line rather than sticking to Tabs for Indentation, Spaces for Alignment (TISA) which seems to be a distinction people would rather just throw out and simplify.
Certainly, though, no matter where you stand on it if you’ve got people mixing it up, which you probably always will unless you employ what I’ve stated elsewhere makes the whole debate moot, it’s going to make a mess either way.
Anyway, yeah, I wasn’t sure how much of that was you just being crude or joking, so..
Unfortunately people don’t make much of an effort to make that clear either. 😉
Larger file size? REALLY? Is that what keeps you up at night?
until you work in a language in which indentation matters and you work as part of a team.
For example, in yaml, you have to use spaces because people with 8 space tabs could be confused with those who use 2 tabs with 4 spaces each.
If you colleagues use 2, 4, or 8 space tabs code will not be aligned for everybody. Only using spaces guarantees it. Readability trumps trying to save bytes.
This isn’t true. You use tabs at the start of the line and everyone can use whatever tab size they prefer. That’s the whole point of tabs! They are useful to mean “one level of indentation” and every reader can decide how big they prefer one level of indentation to be.
“Readability trumps trying to save bytes.”
Especially with the ever-widening gap between how few bytes code requires vs how much bandwidth and storage is available.
Uh, no. If you use the tab *key* and it actually inserts 2, 4, or 8 space *characters* into the code, then you do’t really use tabs, you use spaces. However, if I use actual tab *characters* it doesn’t matter if my editor spaces tabbed content at 2, 4, or 8 spaces, when someone else on the team opens it, his or her editor will show it with his or her preferred amount of space. This is the beauty of tabs. I might like my code super-indented and so my tabs look huge, but someone else might prefer really small indents to take up less horizontal space, and that’s what he or she sees.
Additionally, if someone else prefers spaces, he or she can just tell the editor “change every tab to X spaces” (X being whatever number of spaces he or she prefers) whereas if I use 4 spaces and someone else gets my code and prefers 2, they have to first figure out how many spaces I use for each level, and then run some kind of replace to get things to look how they want it, which is more of a pain.
The main advantage of using spaces is that they always display the same way. I know that those who praise tabs use the same exact argument as a disadvantage (or rather the point that tab can be displayed according to ones preference) but this argument is invalid. There is plenty of places in which such a setting cannot be set. Code nowadays is being read end edited in many different ways, not only with an local instance of editor/IDE installed on a developer machine. Let’s take GitHub as example. GitHub has quite narrow, not configurable code view. Tab is displayed as 8 spaces. This means a lot of code is being ‘soft-wrapped’ and split between lines. Especially inconvenient for side-by-side view of a diff.
GitHub can be configured with CSS. Change tab-size to whatever you want.
You didn’t account for age of developer. Age is likely to track with salary. The reason spaces are encouraged when training coders has to do with printing on paper. So older developers will have a different habit then newer developers.
Readability concerns are valid on screen just as much as on print. I don’t think that is a factor, though age tracking with salary should be accounted for.
yes but readability on a screen that can be resized at will and has in infinite line length ( and also adjust tab spacing automatically) is a very different consideration then readability on a printed page that has a fixed with of 80 characters before it wraps, will be printed in12 pt font and will treat all tabs as representing a specific amount of space and the amount differs on different printing devices etc. Readability is important on both it is just when you have a screen you can adjust at will and software that fixes the tabs so the line up automatically running , tabs aren’t a problem. They become more of a concern on printing devices especially ones that don’t support soft tabs as treat each tab as fixed amount of space.
Interesting hypothesis. I wonder about age correlating with printing on paper; I’m in my twenties but I will sometimes print out code on a piece of paper to examine, just to get away from the monitor and jostle my brain into focusing more on it.
That is not why.
I’ve been a developer since the 80’s. Never once did I think about the ramifications of printing when thinking about spaces or tabs.
It was something driven into me when I was a military contractor in the ’00 because they needed to print documents for code for the customer.
We accounted for years of experience, in both the regression and the first chart.
But not age of developer. There’s a distinction.
We didn’t ask about age in the 2017 survey, but we did in the 2015 survey (as well as asking about tabs/spaces and salary), and the effect on salary is the same. Data here: https://insights.stackoverflow.com/survey
Nor can one find a tendency where developers with the same years of experience that used tabs tended to be younger
Good to know, thanks.
oh, good to know. I don’t see it mentioned in any of your charts or summary so it is hard to tell.
The thing that’s difficult about this explanation is that level of experience tracks pretty consistently.
In general, older employees do have a higher salary floor. However, developers with the same level of experience most likely trained for it around the same time, so they very likely learned the same habits. A 35-year-old with 5 years of experience probably started learning around the same time that a 25-year-old with the same experience did, so they’re more likely to learn the same kinds of habits. I mean it’s possible that some people set aside their development careers for a decade, but I doubt that is a large enough population to explain the results.
If age was a primary factor in the pay gap, I would expect that at the very least, the older languages would stand out in the regression chart.
why, just because I was originally trained in C++ and Modula II doesn’t mean I use them anymore. I’m currently working in C# doing MVC/razor web development. Might be harder to transition to an open source stack because no one has been willing to pay me to work in one, but I am familiar with several. To me it seems like blatant ageism to assume because someone has been in the industry for 20 years they favor or are currently using old languages.
That was not my intent, I apologize. The way I interpreted the post/survey, respondents didn’t have to choose only their current languages, so it seemed natural to assume developers who started earlier would be over-represented in older languages. (To be fair, something like Assembly would probably be more like embedded systems programmers)
Regardless though, we don’t have the age data to do anything more than guess at its effect on the results.
David Robinson
said they did include the age data, but I don’t see it in the charts or elsewhere. So it may already be a disproved hypothesis.
iusenotabsorspacesanywhere
you
should
use
new
line
instead
its
amazing
.
Writing
this
comment
made
me
hate
myself
.
I had a coworker who did essentially this. He also had incredibly long (sometimes 80+ characters!!) names for everything (classes, methods, variables….)
Here’s a made-up example (C++):
ProcConnectionHandle
ProductNameInstrumentSystem
::createNewProcConnection_maybe_fromProcConnectionPool(
ProcConnectionPool& proc_connection_pool,
ProcConnectionStatus proc_connection_status_initial,
MyReadWriteMutexLock my_read_write_mutex_lock_for_proc_connection_pool,
ProcConnectionId proc_connection_id,
ProcConnectionAddressIpv4 proc_connection_address_ipv4,
ProcConnectionPortNumber proc_connection_port_number)
{
……
Wow… You have my sympathy for having had to read that. That’s just awful.
I just switched to spaces. Maybe I should ask for a raise.
spaces 4 lyfe
I hate 17.5% of pro programmers
You can set your editor to automatically translate all tabs to spaces. You’ll be able to love programmers again, since you won’t even notice the ones using tabs—unless they tell you.
Sure he will notice. He will likely set his editor to expand tabs to wrong number of spaces, given how many possibilities there are, and all the code will look fugly.
I’m amazed that so many tab users believe space users press the space key for indentation… Like really? this is so uninsightful I’m almost convinced space users really make more money…
We don’t. Check the other responses to see some space users *actually do* that.
no, they don’t, except in a tv show.
I’d like to think people don’t hammer the space bar, too, but there quite seriously are people who admitted to it right here in the comments; Don’t take my word for it.
Tabs cause problems when reusing code, thats why i use the 4 spaces setting in notepad++ that replaces tabs as thier pressed. best of both worlds, press tab key to get 4 spaces per press.
How? Spaces cause problems when reusing code, . . . same argument can be applied if what you’re talking about is mixing them; Is that what you mean? Really, a good IDE will change spacestabs as applicable, and if that’s not what you mean I’d need a clarification.
Another thing is the size of tabs aren’t always consistant with dofferent fonts… a tab is really just four spaces when typed on paper… personally, for me, a programmer of over 40 years, tabs have always been ugly when coding. not to mention when you start using different character sets. igh it can be a real nightmare…
That’s a terrible argument considering the point is for them to be variable in size, but then again code editors were never made to properly understand tabs. Besides, spaces are generally much more variable than tabs in different fonts, I mean considering you get the whole fixed versus variable width fonts into the argument . . .
AFAIK #9 is #9 regardless of the character set, care to enlighten me on that one?
No i’ll just wait until you’ve gained enough experience to encounter some of the issues that are known to space users, and if you never do then good for you!
I like how you gained at least 6 years of experience in 18 minutes lol “my 34 years” “for me, a programmer of over 40 years”
I mean I agree with you, copy and paste of code (provided you wrote it, trust its author, or at least read it thoroughly) is a pretty normal thing to do. But still, maybe pick a year?
that was a typo lol im on my cell phone. good catch though!
Btw. when you reuse code by copy and pasting you are doing something wrong.
What makes you think copying and pasting is wrong? I think it’s funny that as a professional programmer you would ever even say that. Aparrently you’ve never had a colleague email you a snippet, or reused code from other livraries where you only needed one function, or copied code from a template into a new file. I guess its your ___ years of experience as a programmer vs my 34 years.
Well, that statement was not meant to insult you. It is just that I can still remember my first programing professor telling us ‘everytime you copy and paste code you are doing something wrong’ and over the years there are few statements which I found so true. Yes, sometimes we have boilerplate code which we copy as a template, like a default HTML file. But everytime you copy code you risk that you have to fix a bug in that code in two places at a later time.
So I found that advice very helpful.
Understandable, but I’m not here for programming 101… to insinuate that anyone who would copy and paste code under any circumstance is doing something wrong… is a bit misrepresenting of your own reasoning ability…
40YO senior dev chiming in here. Copy-pasting code is a trap, because you don’t learn anything. Do it consistently for 30 years and you end up like a bunch of other poor old sods I’ve met who stopped learning, and atrophied.
Copy-pasting is not always bad, but copy-pasting from Stack Overflow day in and day out is a deadly, deadly trap.
I can only ask you trust me on that. I’ve seen what it does to people over time.
I think I can respectfully disagree without having to break my reasons down to neutron science.
Why does copy pasting imply not undestanding the code?
Moreover, in my experience, “xxx years senior” labels indicate bad programmers. Good programmers don’t need to use the word “senior”.
I copy and paste code all day along. It saves me hours of time. The alternatives are (A) spend way too much time reinventing the wheel, or (B) pointlessly retype it all out the exact same. Copy -> paste -> review. Every time.
How about using libraries? Or inheritance when you are using an OO language?
Then you acknowledge that copy-pasting the code won’t work if you don’t have the library and can’t reference/include it. If you’re inheriting from a non-existent class and can’t make use of a similar class in your code, you shouldn’t copy-paste. With great power comes great responsibility, or something like that.
Well, I am not sure if you get my point. I am not against code reuse. I say code reuse is great (because it saves a lot of time). I am against duplicating code. So if the code you need exists in a library, use that library. But please do not copy the code from the library, but instead load the library, so that you can easily update it if there comes a better version at a later time.
You’ve obviously never worked on real-life problems.
What about that?
Especially when your clients pay over $100 an hour… You don’t get the luxury of proving you’re a coding ace… Unless you don’t really care about your clients time and trust, and your ego means more to tou. I say copy and paste as much as humanly possible…
A foolish consistency is the hobgoblin of little minds.
Nothing wrong with reusing code by copy pasting.
You’re right, it appears a few confused poor sods do it! However, it’s *far* from the majority, and my point that most people that think otherwise are misguided stands.
Likewise, don’t take my word for it.
That’s also my point, though 🙂 There are *some* people who hammer the space bar, and there are *some* people who think that’s the alternative to using tabs, but that’s far from the majority — on either side.
I think we are both agreeing on that.
Another thingI want to say for notepad++ users is heaven forbid you recieve a file from a colleague who uses tabs when everyone else in the office uses spaces… God that is always a pain in the ass… Same goes for programmers who leave encoding on ascii, but have utf8 characters in their code… definitly annoying.
…and vice versa, so y’know.. we technically agree on that.
As for encoding, yeah, that’s definitely an issue.
Replace leading space with tabs, or replace leading tabs with space. It’s one regular expression: any editor lets you do that. What is the problem?
Oh my, can you imagine? I strongly prefer spaces, but I would rather use tabs than listen to colleagues whack away at their space bars all day. Hell, I’d rather use no indentation at all.
Like really? ANY code/text editore/IDE lets you set your tab key to any amount of spaces you want. I ident with spaces but I’m not stupid enough to smash my space bar 2-6 times for each new line. Come on guys and gals.
I used tabs but configured my editor to put 4 spaces…
So, you don’t use tabs. You use the tab _key_, but you don’t use tabs.
We just figured it out!!!!
People who respond Spaces are those who were smart enough to realize that ‘Tabs’ doesn’t mean “I use the tab key” but rather “I use the tab character”.
‘Tab’ users is ‘Uses Tab Character’ + ‘Uses Tab Key but Space Character, but doesn’t understand the distinction’. My theory is that ‘Uses Tab Character’ has roughly the same salary as ‘Uses Space Character’ but ‘Uses Tab Key and Space Character, but doesn’t understand the distinction’ makes substantially less as to drag down the average.
Using Notepad++, I don’t have to trade tabs for spaces in order to save space. I can setup my tabulations to appear like 2 spaces without having it to be two spaces, which would be 2 characters instead of just one, making all my files larger.
If you’re optimizing for source code file size, you’re doing something wrong.
That applies to almost any IDE for the past 40 years. It’s not a debate about which key you indent with, it’s about which ASCII character.
Or indeed *how many* ASCII characters.
Kind of an interesting situation with Go. From the graph it looks like a dev who uses spaces has a median salary in the 70’s while a dev who uses tabs is in the 50’s. However, any Go developer worth their salt is going to use `go fmt` to reformat their code on save, which will switch to tabs automatically.
A Go user might not only program in Go though, and would indicate tabs. spaces. or both depending on their preference in other languages where they have a choice. But for the purposes of this analysis they still have a set of answers either way for users who also said they use Go.
I took a quick look at the data (30 minutes) and found the following insights regarding Tabs vs. Spaces:
When you split the group into younger and older programmers (not by age but by experience), into the ones with up to 10 years experience (Group A: 37905) and the ones with more than 10 years (Group B: 25308) you can see the following:
In Group A (up to 10 years experience)
Space Users: 26%
Tab Users: 33%
In Group B (more than 10 years experience)
Space Users: 36%
Tab Users: 31%
As Programmers with up to ten years are not only novice programmers, but the ones with a more modern education, this leads me to the conclusion, that it is the result of a modern programming style which favors tabs. Btw. over the whole data set there are alreadey more tab users (16682=32,5%) than spaces users (14666=28,5%).
So my conclusion is that space users probably earn more money as they have more experience, but the trend shows that the new generation tends to favor tabs and that there is already a majority of users who use tabs.
This assumption is controversial to the first chart.
How? Please explain.
You say that space users earn more money as they have more experience, but the chart shows that developers with the same experience makes different amount of money depending on their tabs|spaces preferences.
You are correct, my conclusion is wrong as I did not mean that they earn more money right now, but that they will earn more money in the future as there will be more tab users with more experience and right now the majority of tab users has less experience. So my hypothesis is that tab users will not switch their style when they gain experience but that they will stick with their style and that their group will mature over time and make more money by then. I will correct that.
I have about 9 years of coding and I am a tabber. My father has been coding for almost 40 years and he is a spacer. You hear him all day… bang bang bang bang on the space bar. I put my money on your hypothesis.
I think you might be onto something with the age thing – a 30-year-old junior developer would probably make more than a 20-year-old in the same position due to several factors (better negotiating skills, more ‘real world’ time, that sort of thing).
Though on the other hand, the number of older developers who learned during space days and set it aside until now is probably pretty low, so maybe that’s not the deciding factor…
There are three obvious hypotheses about the evolution of a technical practice when an older generation doesn’t agree with a younger generation.
1) Dinosaur: the old way is going to die off when those dinosaurs go extinct
2) Child: the young way is going to die off when those children grow up and go to war
3) Idealist: the issue will be decided through humble give and take and rational tradeoff analyses
I tried to frame this in terms of insult throwing.
I hit the tab key and it makes spaces appear in Emacs. This is the only true way. /sarcasm
See the links on this JWZ trackback.
https://www.jwz.org/blog/2017/06/developers-who-use-spaces-make-more-money-than-those-who-use-tabs/
Key quote: “My opinion is that the best way to solve the technical issues is to mandate that the ASCII #9 TAB character never appear in disk files: program your editor to expand TABs to an appropriate number of spaces before writing the lines to disk.”
I tried using Spaces once, it was awful
my salary kept increasing beyond control, I eventually had to go back to tabs
LOVE IT. 😀 😀 😀
https://imgs.xkcd.com/comics/correlation.png
I scrolled down to post this same xkcd : ))
You didn’t read the article did you? I will help you out:
“Correlation is not causation, and we can never be sure that we’ve controlled for all the confounding factors present in a dataset. If you’re a data scientist, statistician, or analyst, I encourage you to download download the raw survey data and examine it for yourself.”
Did read, and I recognize the author recognizes that as well as did statistical effort to explore the dat. Still funny. 😉
A couple of paragraphs before that one it reads:
“The model estimated that using spaces instead of tabs leads to a 8.6% higher salary […]”
Despite the disclaimer in the conclusion, that statement implies causation.
Fun joke. Not relevant here. The author was clear that correlation != causation. Several times.
I’m a 32nd Degree Master Tabster
Spaces is the right answer, no matter what. Most languages are multy-platform. Spaces looks same on any platform and this is not the case for tabs. Just accept it.
spaces gives way to the “how many” discussion, while tabs can be formatted to taste and there is no “how many spaces” discussion.
computers (parsers, compilers) don’t care, so there is no technical argument.
= there is no right answer, it is a matter of convention / doctrine
disclaimer: using spaces but hate having to reformat files (and ruin the git annotation that way) to the point where i think: tabs don’t have this issue.
lol explain this to my boss who is unapologetically a tabs man.
The whole point of formatting is to make code readable to OTHER humans. Wouldn’t it be nice if there were a technology that adapted to everyone’s personal preference.?
With spaces though you have different developers who use different numbers for each level of indentation. With tabs one tab is always one level of indentation. As for “looking the same,” any person on any platform can make tabs look however they want, or change them to their preferred number of spaces, with a single keypress.
..
The HTML in this clickbait is tabbed with tabs.
People are over using the word “clickbait”. The title of this blog is in no way shape or form clickbait. Click bait would be:
“Some programmers make more money that others, read the SHOCKING reason why!!!”
“Google Developers hate him! Learn how he increased his salary with this one little trick!”
They actually mix tabs and spaces.
Dude. This is a brilliant study idea, but you should modify your result to only apply to the sampled. This is an observational study, so you can’t claim causation. Visual analysis of confounding variables isn’t enough to claim causation. That being said, you *could* do some random sampling and randomly assign treatment groups if you raise a bunch of babies, randomly indoctrinating them from age 3 to either tabs or spaces, and tracking their salaries over time (with some mechanism to handle serial effects).
Anyway, yeah, what xkcd said. But still, brilliant idea 🙂
The article itself says “Correlation is not causation, and we can never be sure that we’ve controlled for all the confounding factors present in a dataset.”
WHAT KIND OF CIRCLE JERK POST IS THIS…….
I would have expected better from stackoverflow.
There is no reason given in the article to explain why.
Correlation is not equal to Causation.
Did you even read the conclusion?
Yes, they even say that in their post. It’s just an interesting piece of data. They have no idea why it is, it just is.
You didn’t read the article did you? I will help you out:
“Correlation is not causation, and we can never be sure that we’ve controlled for all the confounding factors present in a dataset. If you’re a data scientist, statistician, or analyst, I encourage you to download download the raw survey data and examine it for yourself.”
It says Correlation is not Causation in the conclusion. This is an interesting and amusing article and that’s all.
Add a new question on to the survey for next year asking if developers limit character length of their lines to 80 characters. Then see if this correlates with space-use.
What of developers who mix tabs and spaces? 😛
They are to be exiled to a horrific world where the only language available is PHP and the only editor is ed.
the only language should be something worse…
COBOL?
If it were worse than PHP, they might give up. PHP is just barely viable enough to entice them to keep going, thus prolonging their suffering.
Or JavaScript.
It actually describes people who replied “Both” as being indistinguishable to just tabs.
Both is not the same as mixed. I would reply “both”, because I use tabs for some programming languages, and spaces for other languages — but never both in the same document. *Mixing* tabs and spaces, on the other hand, implies using tabs and spaces within the same document (and indeed, sometimes on the same line).
RTFA
Please tell me where the article talks of _mixing_ tabs and spaces? Using both tabs and spaces is not the same: I use tabs for some languages, and spaces for others. I never mix the two in a single document.
It’s referenced right there in the very first graph and paragraph. You really didn’t read, did you…
It references ‘using’ both tabs and spaces not mixing them. At Cratejoy, we use spaces in Python and tabs for Javascript and Less but we never mix tabs and spaces in a file.
Please learn to read what the article actually says, not what you think it says. 😛
“Both” is not the same as “mixed”. I use both tabs and spaces, because I use tabs for some programming languages, and spaces for other languages — but I never mix them: never both in the same document. Mixing tabs and spaces implies using tabs and spaces within the same document (and indeed, sometimes on the same line).
opinionated and irrelevant. also incorrect findings.
I like think most people reading this would see it the opposite way and as a great example of meaningless correlation between what comes down to stylistic preferences (in most cases).
What are the correct findings?
Also, what’s the “opinion” being presented here? The author is presenting data and even states that the results are “surprising” and unexpected.
It is my opinion that the title is the opinion. The data sample is flawed in that his sample was chosen in a way that has a misleading trend that fits the title of the article to make it look like the correlation is the cause, when the statistic says more about his sampling techniques than it does about who gets paid more.
For example, only people who knew about this survey or visited a certain site or subset of sites were surveyed. To illustrate: “Just because most people from a certain state might be ass[hat]s doesn’t mean that living there makes you that way.”
OP, have a frickin snack.
Er, what sampling techniques are you referring to, exactly? The sample is the set of people who took the Stack Overflow survey and answered that question. So obviously a self self-selecting sample, but they did their best to advertise the survey and encourage people to take it, so it’s in no way clear to me that there was a better technique available or that there’s any obvious reason for the sample to over-represent high-earning space users and low-earning tab users.
Also, the title is still not an opinion; it’s the conclusion drawn from the (publicly available) data.
Here is a simple explanation: Younger programmers who are just getting started (say, with less than 5 years of experience) do not know the value of readable code (and thus use the tab character to push code farther to the right than spaces), and they do not know all the bells and whistles of their IDE or text editor, so they don’t know that the tab key can be mapped to add spaces.
More experienced programmers:
1. understand the value of compressing more code into horizontal width (for easier reading) AND
2. read StackoverFlow/Usenet and understand that other experienced programmers use spaces AND
3. know how to change the settings of their IDE to emit spaces when the tab key is pressed.
Well, 1 doesn’t apply size the whole point of tabs is to be able to adjust them (if you prefer one space indentation, hey, tabs make that real easy and you don’t have to ask anyone to change it too) and 2 is more pedantism than experience. Really, spaces just mean “I gave up and didn’t want to deal with my tools”.
That’d all make sense except that first chart shows that space developers make more than tab developers on average even with the exact same amount of time in the career field.
Look at the text again: “I fit a linear regression”. A linear regression coefficient tells you how much of the change in the response variable is due to a given input variable *if we hold all other input variables constant*. The linear regression included both programmer experience and tabs vs spaces, so the effect exists even beyond programming experience.
Your first point doesn’t make any sense. Tabs don’t really make code less readable since you can configure your editor or IDE to represent tabs with any amount of space (or any number of spaces) you wish.
This also makes tabs more versatile, since it’s more difficult taking code with spaces for indentations and modifying it to look how you want (one tab is always equal to one “level” of indentation, whereas different developers use different numbers of spaces for “levels” of indentation). So while anyone who prefers spaces to tabs can take code with tabs and instantly convert it to spaces, or make the tab distance equal to two (or four, or whatever) spaces for readability with a single keypress, someone who prefers two spaces per indent level will have a harder time making code with four spaces per indent level readable to him or her.
I’ve been a developer for 25 years and I use tabs, and I know how to change my editors and IDEs to emit spaces when I press the tab key (and also just to set my tab width so I can use less horizontal space without futzing with spaces), so your second and third points don’t really make sense either.
You missed my point 3, didn’t you? Because you are an experienced programmer, you know how to set your IDE to do these tricks, but an inexperienced programmer does not (or does not value doing so).
No, you missed the part of my reply addressing your point 3, “…I know how to change my editors and IDEs to emit spaces when I press the tab key…”
Tabs are good. I can’t agree with this post
You can’t agree with Statistical Analysis of a data-set of survey responses? This post didn’t show anything to agree or disagree with, it didn’t say one was better than the other, it showed a result from a collected survey.
The article makes no claims about the technical merits of tabs vs spaces. It just points out the existence of a correlation.
“The StockExchange of tabbed programmers at wallstreet was dropped by 40 points 5 minutes after this post was published.”
N.Y.T – 6/15/17
elastic tabstops ftw
If only, if only, if only….
Take THAT Richard Hendriks!
I used to be a strong tab supporter. I would say “just configure your IDE/editor to show however many spaces you want per tab”. Want 4 spaces, 6, 8 spaces? It’s just an IDE issue. Then I joined teams where the 2 were being mixed all over the place. Now I’m a spaces guy. Because what I see on my screen is what you’ll see on your screen, and vice versa, no matter what. It took me 5 years to realize the importance of this. Spaces > Tabs.
I’m confused. Once you’ve configured your IDE to convert tabs to spaces, that already solves the issue you mentioned. Are you saying you literally press the space bar for indentation?
I think he’s saying that as soon as one developer on the team decides to use spaces then everyone is forced to.
Forced to explain to that one developer that they’re part of a team?
Haha, of course not. What I’m saying is the mix of tabs and spaces in code that’s being touched by a team of people, each using their preferred IDE/editor and settings. Some using actual tabs, others using spaces. It get’s annoying fast.
Personally these are my preferred settings (vim):
set tabstop=4
set expandtab
set softtabstop=4
set shiftwidth=4
What do those settings mean for those of us who aren’t Linux vim programmers?
A tab key gets converted to 4 spaces. A back space at a position of “column mod 4 == 0” removes 4 spaces. So you get space characters from tab keys but that also behave like tabs on backspaces too. This is especially nice for python, my go-to money maker.
No. He’s saying that he used to have his tab key insert the tab character. He liked that because you can configure how many spaces your IDE renders a TAB as. If you want tabs to look like 4 spaces, you can set that. If 2, you can set that as well. The IDE will render the tab how you wish, but it’s still a tab character in the file.
He discovered that was a problem in files that mixed tabs and spaces because how your IDE renders tabs might differ from how many spaces someone inserted. If everybody uses spaces and not tab characters, the file will render the same for everyone. I’m sure the OP uses the tab key to insert his space-character indents.
My hypothesis: Somebody who touts their use of spaces is more likely to exaggerate their reported income. It sounds pretentious. “I am above using tabs” or “I am better than you”.
also.. fwiw:
set tabstop=4
set expandtab
set softtabstop=4
set shiftwidth=4
End of discussion.
I added this to my vimrc and my boss just bumped my salary! Thanks!
https://stackoverflow.com/questions/2131213/can-you-make-valid-makefiles-without-tab-characters
Ctrl+v -> tab -> outputs a tab character regardless of the above config in vim. TMYK
Me too! 🙂
Thankfully, vim’s default Makefile config unsets ‘expandtab’.
cool! didn’t know that.
ITYM
(set-default ‘indent-tabs-mode nil)
So, one who uses space instead of tabs makes more money!!! How is this logical?
The coice of programming language influences the decision of spaces vs. tabs.
The author adjusted for that.
“…this is certainly a surprising result, one that I didn’t expect to find when I started exploring the data.”
The point of empirical investigation is not “logic” but merely data collection and statistical analysis. The fact that something is true doesn’t make it logical, nor are logically sound ideas necessarily true.
Maybe the title of this article should be “Developers who use spaces more likely to exaggerate salary claims”?
Great! Meanwhile blocker bugs in the SO/SE sites are well and alive! Way to go!
One of these days we’ll convince our data scientists to stop looking at data and fix bugs instead. Don’t give up hope!
Perhaps we could, instead, convince SO to hire more/better developers instead of wasting money on data scientists who apparently have little enough useful work to do that they have quite a bit of time to waste?
And yes, I’m aware that SO have job ads out, so they’re trying to hire developers. Maybe the problem is in the supply chain: too many people being trained as data scientists, and too few as developers (though in fairness, the data scientists I’ve met don’t strike me as people who’d be great developers if they had different training).
This argument of “meanwhile, […]” is very unsound. Like, meanwhile, children are dying in africa, stop using your computer and do something about it. If your job is not in health, teaching or food making, you are useless, so you should stop wasting your time.
kids these days…
You have enough work to justify the salaries of more than one data scientist?
Mah gawd you guys, who cares? Its a big company, you don’t complain about random studies that Google does, do you? While some studies may seem pointless, one could argue that all minute studies are pointless given no context, yet here we are talking to each other through the internet, having never met in real life, because of what were arguably at the time an enormous quantity of “pointless studies” done throughout history to sufficiently advance technology to the point that we can do exactly this.
If we put this kind of scrutiny on the SO data scientists, imagine what kind of scrutiny we could put on what YOU do all day, such as…. oh, I don’t know, read the “pointless studies” that you’re complaining about, and then comment on replies of comments, perhaps?
Hmmmmmmm?
Hmmmmmmmmmmmmmmm?
[trollface]
One
of these groups is skilled enough to modify their editor to replace `TAB` with two spaces. The others can’t figure out how to exit vim.
Ctrl+Z, pkill -9 vi 😉
Really the best way to deal with primitive software that one should not be writing code in.
Some of the best devs on the planet use vim. It’s a badge of honour.
The majority of the devs on the frontier of new languages, and language research, use an editor like vim. The IDEs haven’t been created yet.
The majority of what I hear from that field is editors like sublime & np++, where one can define/redefine new language syntax on the fly to test with syntax checking and iterate quickly.
That’s fine for lazier people, but acting like you can iterate faster by preferring them to vim is just dishonest.
To be sure. I’ve seen some godamn wizards with vi, but in 30 years, the wizards will be using the more evolved tools, because they offer better returns for the same experience. Mostly, anyway, I don’t think console editors will ever obsolesce completely, but it does a disservice to developers to push tools like vim as objectively better, as people tend to do.
In 30 years, vi will 71 years old, and vim will be 55 years old. All of us are hoping for better, more functional tools in that timeframe. But for now, the universality and raw power of vi & vim is hard to ignore.
As a vi user myself since the early 80s, I’m not really seeing that happening (though I’d be quite interested to be proved wrong). I’ll be the first to admit that Emacs has it all over vim when it comes to power, but I don’t use vim because it’s a powerful editor: I use it because it makes life really easy when doing basic text editing through features such as keeping my fingers on the home row. Everything else happens in another window at a shell prompt.
when I want to make editing more efficient, I fix my language or write a new one, which has the added advantage of making reading, as well as editing, more efficient. When I need to make anything else more efficient, I update my command-line programs.
Don’t take this as me trying to dis Emacs or your particular editor/IDE/working method/whatever of choice here. It’s not that I don’t do that (I think that Textmate is an abomination that should be wiped off the earth with all of it’s users, for example), but I do recognise that what experienced people do in Emacs-land can be just as productive as my way of working. I just want to point out that experienced vim users are using an entire ecosystem of tools, just not vim, do pointing out that vim doesn’t do X doesn’t mean that vim users can’t or don’t do X. There’s no reason everything you do has to be done by you editor.
Well, actually it depends on what you value. If you want something feature rich, an IDE might be objectively better. If you just want to edit a few lines of source code, the small editor which is just an editor might be objectively better.
The power of Vim is that it starts as a very small and slick editor but can become a feature rich slow mess with the right plugins 😉 I am sure this is nothing new to you, I just wanted to say that ‘objectively better’ says nothing without any KPIs.
Yeah right – like we need to memorize a zillion keyboard shortcuts to do the most obvious stuff !!
Keeping up with tech is tough as it is, we need our memory for more important stuff.
Turn it off and on again.
Did you just assume how many spaces I use for tabs?!
Is that like assuming your gender?
4 spaces for Windows devs.
“Here’s a nickel kid, get yourself a real whitespace character.”
:!sudo shutdown -P nowBiggest bullshit I’ve ever read
Sounds like you must be a tab user. BURN THE HERETIC!
If you insist, heretic. Stand still.
dude… calm down.
that’s exactly the intention of the author – using the temptative conclusions of an association study to teach sth else. it’s satirical..
I suggest the ones using spaces might be largely the ones who believe they are better and have higher standards when negotiating a salary. Which is not necessarily a bad thing.
People who respond ‘Spaces’ are those who were able to differentiate between “I use the tab key” and “I use the tab character”.
‘Tabs’ and ‘Both’ users include:
1. Developers who cannot understand the distinction between ‘Uses Tab Character’ and ‘Uses Tab Key but Space Character’
2. Developers who cannot extrapolate full solutions from limited information.
2. Developers who understand the distinction but don’t care about consistency.
3. Developers who don’t/can’t change the IDE default settings.
My theory is that ‘Uses Tab Character’ has roughly the same salary as ‘Uses Space Character’ but those who doesn’t understand the distinction make substantially less as to drag down the average for ‘Tabs’ and ‘Both’.
Funny, a few days ago, I would have found unbelievable that someone would actually think of tabs as the tab key. Reading the comments here, I am baffled to see that not only do some really don’t see the difference, but these also think space users actually use the space key….
Amazing.
I blame that episode of Silicon Valley 🙂
But in all seriousness, yes, this is a rather mind-bending discovery.
It also bends my mind that some people fail to understand that the ambiguity inherent in using tab characters is the very reason why space characters are strongly preferred by anyone capable of thinking logically.
That ambiguity is a feature of tabs, not a bug. Those of us that like compact code with two space indentation can coexist peacefully with our coworkers that use 4 space tabs. As long as tab characters are in the code it is just a editor setting and both groups can be happy. Even that one weirdo that prefers 8 spaces per tab can do his thing without bothering the rest of us.
If you genuinely think ambiguity is a feature then I can only conclude you’ve never had to work with timezones and DST transitions 🙂
do you even read? medians differ
You’re right. Fixed it from average to median. Though the argument still stands either way. The volume of low salary developers who cannot make the distinction brings down the median.
Maybe developers that use spaces exaggerate.
You’re probably right as we all know you can’t trust developers that use spaces.
It’s simple. Programmers get paid per character.
Salary aside, I was a tabber for decades. And it was the predominant coding standard at many of my employers and clients. Then one day my friend and colleague Doug Y. remarked “tabs have to be rendered, spaces do not”. That tiny little piece of wisdom was my Road to Damascus moment. I’ve been a spacer ever since.
They disappear when its minified.
There is a bit of throwback in it. Tabs are faster to type, and IDE replacement is relatively new. Tabs are also a single character, and code files not having to count bytes is also relatively new. There is a lot of lag between the professional world moving past a paradigm, the educational world adopting that change, and the post-change students getting into the workforce.
How much relative? I’ve been to a VB6 project where we used the tab key for inserting spaces. VB6 IDE is even smart enough to understand where the level of indentation ends and add only the correct amount of spaces…
30 years. While that’s a lot in technology terms, it’s below the turnaround rate for a lot of major universities. I say this from experience both as a student coming out with 30 year out-of-date habits that I had to get rid of, and having trained several recent grads out of their school-taught habits that were based on green-screen limitations.
wow, thank you for your cumpliment 🙂 now I feel I am myself relatively young hehehe (I am 30 years old)
ok… so you are talking about 30 year old IDEs that can’t automatically transform a tab into spaces… I guess if I were a programmer back then, I would most likely only use tabs and ask myself why would anybody use spaces instead because you would need to hit the space bar 4 times while the tab does it in one…
But we are talking about the present and in the present, nobody is required to hit the spacebar 4 times for each indentation level. Even if you are working with such an old language because you can use other editors instead of those IDEs
I’m older, but not quite that much older than you (I deny the existence of the looming 40). Contrary to popular belief, you can learn about obsolete things. 😛
I suppose I do have an “advantage” in that area because I’m from a rural area. My high school was teaching us to use computers on green screen terminals in the late 90s. My first year of college, I coded for a Fortran77 compiler, was assigned a 286 frankencomputer for a literary club I joined (as the only technical person in the club, I got saddled with making it work), logged into yet another green screen terminal for submitting projects in, ironically, my C++ class (The Fortran class was submitted on disk, but was compiled through DOS command line on Windows 95 computers), and got lectures on file space limitations that were prefaced by an explanation of old technology. In most of my classes, there were then-modern IDE options available, but the free versions often weren’t compatible with our archaic compilers.
I also worked as an adjunct professor for a while, and as part of the IT staff for a college, and with IT professors from 5 other universities. The problem is the university’s internal cycles, and how long it takes to get a degree and teach a professor. A study I read while looking into it while arguing with a professor over it is where I’m getting the specific “30 year” figure, so my 30 years is itself almost 20 years out of date. I do still keep in touch with universities, though, and it’s not getting a lot better. In my state, I suspect it’s going to get worse now that our governor has decided to gut the education system in favor of his ego.
As for the present, no one is sitting over your shoulder telling you to change your typing habits. If you picked up the habit of rapidspacing in college, there’s no impetus to change it.
Yes, nobody needs to be over your shoulder telling you to change your typing habits, because it is not needed anymore. It doesn’t really make much difference…
I think causation is backwards here.
Programmers that get paid more are more likely to be required to use spaces. I have never worked at a large company with a coding standard that requires tabs over spaces.
Interestingly, I’ve never worked at a company that stated which pattern we should use, but never seen a professional code where tabs were been historically used instead of spaces. I have used tabs only during the course of my graduation where everything works and looks good. The real world requires you to use spaces.
I think you got it!
Spaces are more likely required when working on a code base that more than one person is working on, since you don’t know how someone’s editor will render tabs (2 characters, 4, 8?). People using tabs work at larger companies and therefore make more money.
And of course that was a typo….
“People using SPACES work at larger companies and therefore make more money.”
Company size seems to have been controlled for though. I’d expect that to be a good enough proxy for team size.
Perhaps it’s that, all else being equal, maintaining a codebase with tabs requires a small amount of extra effort which could have been spent on shipping features 🙂
If one never shares code, or has no concern for the next reader (who may use a different editor) tabs/spaces don’t make much difference. So, developers who know the difference (and care about the NEXT reader of their code) use spaces to preserve their formatting across tabstop changes. I’d argue that developers who care about the next reader are just better at coding.
Most people in office environments work with a mandated IDE, eliminating the tabstop change question. That said, companies that allow diverse environments or working from personal equipment might pay more but require spaces for that reason.
This is all self-reported, yes? What if the conclusion is spaces developers are just inflating their salaries by 8.6%? [trollface]
I think the survey could have been poorly developed. I didn’t have the chance to answer it, so I can’t really be certain of this, but before asking if people use tabs or spaces, you need to clarify that you are talking about the tab character against 2 or 4 space characters in indentation.
Those in the beginning of their careers might not understand or even know that the IDE can change the tab key output to spaces, which could explain the lower salary. Also, people with longer experience who still don’t get this, might be the kind of people who are not curious enough to enter the IDE configuration and test possibilities. They tend to only do what they are told.
My theory is that creative people tend to earn more and changing the default configurations could have correlation in this data.
Or they could know what the IDE configuration is, but assume the question is about which key they press. Like you, I didn’t get asked the question, but in the way it’s phrased above I would say “tabs” even though one IDE converts them into spaces and another doesn’t (putting me in “both”). If I were in only the IDE that converts to spaces, I’d be saying “tabs” even though my output was “spaces”.
Gonzol, if they were asking for which key one presses for identing, my guess is that 90% would reply “tabs” and not 40%.
Also, there is no technical difference between using the key tab or the key space making it irrelevant for a survey, while there are technical differences between the character tab and the character space such as filesize and indentation of lines of code written in more than one actual text line or languages without a clear indentation pattern like SQL.
Filesize hasn’t really been treated as a factor since the late 90s. The tab/space characters go away when you compile if it’s a compiled language, and they go away when you minify if it’s a transmitted language. The only difference the actual character makes is in display across multiple IDE configurations. And that actually benefits tabs unless someone goes along typing spaces (sort of like someone shoving fixed-width objects in the midst of a variable width HTML page).
It doesn’t matter if it has only been treated as a factor recently. It is treated as a factor in the present and that is what matters for a survey about the present.
In any case, neither of us have answered the survey, which means we can’t really know what they meant by “tabs or spaces”. I just think that a lot more people would use the tab key instead of the space key for indentation and not only 40% and that’s why I think that or they were specifically talking about the character or they didn’t make it clear
I’d also ask for more money if my boss insisted on spaces. Like I have nothing better to do all day long than correcting code that starts in columns that are not multiples of 4…
I don’t know which IDE you use, but I’m pretty sure you can use it to autoindent…
Most IDEs nowadays will have an automatic document formatter. Configure it properly with your team’s standards and never worry about code styles again.
And for those of us not using IDEs – anyone with any technical competence can run a CL linter, autoformater, or bang out our own script in a few minutes to address the issue permanently.
My point is: No competent dev needs to waste much time dealing with the problem of spaces.
Just out of curiosity… Why would anybody not use an IDE?
In some languages it’s faster and easier to write your code in a text editor than in an IDE. This is mostly the case for older languages or specialized languages based on old languages that aren’t object oriented. Also an IDE takes much longer to load than a text editor, which means if you’re testing something and can’t keep your IDE open through the testing, you’re going to prefer using a text editor.
Nutarama, must be a really old language, then. I had this issue in the past. My first professional coding language was FoxPro for DOS. Its IDE was great for building windows in the DOS environment and all, but the actual coding I used to do on Notepad++.
At that, I used to think of Notepad++ a lot more like an IDE than the actual FoxPro IDE inside DOS…
If you are refering to this kind of text editor, like the recent VSCode, I would still consider them as IDEs.
My second language was FORTRAN, which we did entirely in notepad, not even Notepad++. Then ended up using a slightly fancier text editor to write some code in a proprietary language very similar to FORTRAN. If you’re counting Notepad++ as an IDE, I’d agree much more with your idea. To me, if something’s not labeled as an IDE, then it’s not an IDE.
My first code that went on to be compiled and executed (with a runtime error) was FORTRAN written on paper, which then went to card punchers, who created the card stack, which was then fed into the specialized reader. For maybe 30 lines of code (probably less – it was a very long time ago) it then produced several tens of printed pages, on special paper used by dot matrix printers.
Or it can be a modern DSL which you/your team created, for a particular project. It’s usually a lot easier to configure syntax highlighting in an editor than in an IDE, which, especially for small files, makes a plain text editor a lot more convenient.
for starters:
– Bloated, resource hog, slow execution
– Overwhelming installation, dependency tree nightmares
– Inconsistent availability
– IDE does the wrong thing – interferes with coding
– Doesn’t integrate with tools correctly (forcing external compile/debug)
Yes. I’ve had to use some IDEs which were not highly configurable. Sometimes its actually better to use vim or emacs, even if you have to write your own extensions to replace missing IDE functionality.
To a large extent, those are IDE configuration issues. If you don’t install what you don’t need, IDEs can be quite nimble and either do nothing or do the right thing. Plus, although not as straightforward, they’re as extensible the way you want them as emacs (vi is a bit of a different story, IME).
Some people must do a lot of their work on a remote server, and use vim, emacs, or similar over the terminal.
Others are using less popular languages for which the best working environment is vim or emacs. There may be no IDE, or it may be under developed. Eventually these languages may get high quality IDE support, but until then…
For other people, they need to pick up a project in a language they’ve not used for many years, make improvements fast, and move on to another project in other language. Sometimes it may be easier and faster for them to use vim/emacs/similar than it is to deal with the unfamiliarity and peculiarities of the IDE which one conventionally uses for that kind of project.
Related – when I first started creating Android apps, I was _much_ faster in vim than I was in eclipse. I forced myself to learn eclipse (and now intelliJ). But even today – even though I’m very familiar w/ android studio, and use the vim plugin, there are still occasionally special cases where its still better for me to switch to true vim. As awesome as android studio is, there are things it just can’t do efficiently, or at all.
Also, you can consider the long term benefit of the time invested mastering various tools. I’ve gotten competent at several IDEs only to have them fall out of favor, such as eclipse. Vim/emacs are always there. Languages and IDEs come in and out of fashion, and sometimes evolve quickly. If you are looking at “lifetime skills” which are empowering for decades mastering vim and/or emacs is well worth the effort.
I’d like to suggest initial coding style education as the compounding variable. Teachers who emphasize good coding style are more likely to emphasize the use of particular spacing (and thus passively suggest using spaces instead of tabs) than teachers who do not emphasize good coding style. Students who had the former teachers will generally have better style, apart from space usage, than students who had the latter teachers. Also, students who had the former teachers are more likely to use spaces than students who had the latter teachers. Students with better style (regardless of space usage) will earn higher salaries, so a correlation between space usage and salary will appear.
Personally, good coding style was a major emphasis in my first computer science (Java) class. We were taught to use four spaces to indent each line. I started off using spaces, but later switched to tabs. If I need to submit code with spaces, I will write the code with tabs and then Replace All tabs with four (or two or however many) space characters (and increase the file size), or configure my IDE to do this automatically. Other than space usage, I am very persistent on style and will fix the style of code I receive before I read or compile it. Because of my positive style habits, I anticipate that I will be in the “Spaces” category of developers as far as salary goes.
Look at hiring habits, though. Very few companies or even startups use code samples from applicant’s own IDE. Most give practical tests or carelessly don’t check code at all. Despite some idealism about style consistency, most employers just don’t care as long as it meets certain readability requirements such as using the right casing and not exceeding a threshold in a calculated cyclomatic complexity.
You might be right that it is based on the institution, though. Graduates from well recognized universities or those with good placement programs have a better average salary than others, regardless of the quality of the particular program. If we apply this to IT, some particular program in the past could have spread the “spaces” style mistake to well-placed people, resulting in a lot of well-paid coders who don’t know where the tab key is.
About fixing the style, I used to do that as well, but I had problems with higher ranks because of that, so now I only do it if I’m going to modify a lot that piece of code… Some companies don’t really care about the readability of code. They just want the code to be delivered because the client is waiting for it.
My hypothesis: The element of tradition in education plays a role, i.e. the confounding factor is by whom the respondent has been implicitly or explicitly taught.
My hypothesis: The element of tradition in education plays a role, i.e. the confounding factor is by whom the respondent has been implicitly or explicitly taught. Call it genealogy of mentors. This information can’t be extracted from the available survey, thus it can’t be tested at this point. But I predict that you won’t find any other causation in this data regarding the correlation of spaces/tabs vs. salary.
But how many of those space devs are required to use spaces because of code style guides at their respective companies? Regardless of whether or not they choose to use spaces on their own.
The position of Go in the language graph raises some questions: +$20k/yr for Go devs who use only spaces!? Code in Go is autoformatted with tabs by convention, and a large majority of open-source golang code is autoformatted with tabs this way. Either there’s a big underground community of highly-paid go devs secretly writing their code with spaces, or — way more likely in my opinion — the data is off and go devs who should have answered “Both” said “Spaces” because that’s what they prefer or what they use in other languages where there’s actually a choice to be made.
Or only very few people answered go and spaces, and so the sample size in that specific case is small.
I assume language choice was a multi-select option? Might be interesting to correlate # of languages selected rather than treat each individually. I’m thinking maybe space users are more likely to use multiple languages, and multiple language fluency would correlate with higher compensation for multiple reasons.
Go programmers who “use spaces” can still use spaces even if gofmt uses tabs. It’s as easy as a couple of lines in a .vimrc that should probably already be there to begin with.
Is having to use vi worth the higher salary?
Clearly employers are paying developers by the byte.
Me own bytes go to eleven.
I automated that promotion for those that are interested 😉
https://gist.github.com/ibarrajo/74a03b135079ee23f3ae0250de11fe4c
It’s quite simple, people who use spaces think they’re the best and will happily share their salary etc, whereas Tab users are a lot more modest and rather not share. The 50% of people who didn’t share their income contains all of the higher paid; modest Tab users. And little Space users.
… more like, tab users are sour all over the place 😉
as you may have noticed, the only people resorting to name calling, are name calling the space users.
Literally none have said stuff like “we’re better”.
It’s a very reasonable explanation, supported by the evidence.
Could it just be that the ‘spaces’ method is an older form of code formatting and that older programmers using spaces have the advantage of seniority therefore earning more money? So it’s not that using spaces earns you more money, it’s your seniority that explains a higher salary …
See the first graph; the effect exists within each level of years of experience.
Dude did you even read the article? Years of experience was literally the FIRST confounding factor that they controlled for.
Totally blew past that, I guess I need to refill my cup of coffee big time. Apologies
Years of coding does not necessarily track perfectly with age (e.g. some of the people using spaces could be folks who started coding later in life, or who have spent more years of their career in non-coding positions, especially management), so it could possibly still be a confounding variable
That would still rest on the assumption that older developers did not have the tab character available to them. It being part of the original ASCII set, which goes back to the 1960s, so this is so unlikely as to not be worth mentioning.
It’s not the spaces that make you more money. The best paying companies usually mandate that you should use spaces. The whole spaces and earnings thing is one giant fallacy from the ground up, mixing up the cause and the effect.
They mandate it because it facilitates working in a team, and because the people making that call are senior devs who have experienced the pain of mixed tabs/spaces.
I don’t think so. IME, they mandate it because furniture police. They could as easily mandate using tabs exclusively for indent – a style checker can warn of mixes on commit. More often than not, very senior developers prefer tabs, not because it adds any stylistic or technical value, not at all because it saves a few bytes on disk, but simply because it makes sense. In a given editor, a tab has always exactly the same width. It happens to me repeatedly that upon code reorganization the IDE mixes up indentation, and unless I want my whole file reformatted (like all javadoc comments messed up) I need to fix this manually. What’s more, a wise man once said that it isn’t typing that slows you down, when coding. Using spaces for indentation is simply a dogma that has caught on among enterprise developers. But it doesn’t really have any advantage over using tabs. Of course, mixing tabs and spaces is plain stupid, but if tabs for indent proponents can do the mix, so can spaces for indent proponents do it.
Typing spaces just takes more time, thus per/hour it is more expensive. That simple 😊
Many editors such as PyCharm do spaces automatically when you hit TAB key
Yes. Pretty much _all_ editors and IDEs which any real programmer would use, allow this to be configured.
All modern editors do this. Every single one.
…. you really think people use the space key to insert the spaces?
https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/#comment-3363700432
… you really think this was not a joke ?
Yes. Read the comments a bit more. Many people are actually making that assumption, very seriously.
Though, maybe there are some jokes in there, but judging from the general sourness in the comments of tabs users, I don’t find it hard to think 😉
… and if it were, I’d still argue it is getting really old, having been made like 30 times already…
I don’t think anyone who uses spaces over tabs types the spaces individually. The IDE does it automatically for you.
If you’re filling out a survey on Stackoverflow, and you are asked if you use “spaces” or “tabs”, are you going to answer based on what key you pressed, or on what your IDE did for you? I would answer “tabs” even if my IDE converts them into spaces. You also would see the effect dramatically decrease when controlling for language as some languages don’t have an IDE that does spacing automatically. This is indeed talking about typed spaces.
Of course you’d answer based on what the character actually is in your script, that’s the whole point of the debate. Adaptable tab size does not refer to your keyboard!
Languages don’t “have” ides. Text editors can edit any text in the world, in any language, and you can control indentation of your text editor.
Considering the comments here, the two of us may be demonstrating the divide. It’s not that we “don’t know the difference” as a certain person put it above, it’s that the question is being presented in a way that some of us think you are (like people we know in the workplace) pressing the space key rapidly every time you want to start a new indention level.
If it were actually about consistency, tab use and tabstop size would be mandated instead of requiring spaces since you can’t type part of a tab. It isn’t about readability because people configure tabstops how they prefer to read indentation. Take away all the flimsy arguments that don’t actually hold up when you think about them and you’re left with only 1 tradeoff: The benefit of consistently using tab characters is that they adapt to the display preferences of the individual programmer. The benefit of space characters is that tab characters adapting to the display preferences of the individual programmer suddenly look weird when one idiot presses the space character a bunch of times instead of using tab. If we didn’t have people who actually pressed the space bar multiple times, we would all be using tab characters.
It won’t matter if you’re only looking at code in the same IDE on the same platform.
If you use diff/merge tools or a platform like Github where the diffs are shown in a browser, the whitespace formatting becomes a huge issue.
Always convert tabs to spaces, because you can’t set every tool to use the same tab size.
In an exemplification of the eminent flexibility of tabs, this is easily resolved with a .editorconfig file in your repository root, which GitHub will respect when displaying your source files in the browser.
Except sometimes you want alignment that isn’t easily achieved using tabs, such as lining up the colons in a dictionary. Then you have to use mixed tabs and spaces, and you will only cause pain for any other developer who tries to edit your work.
I’m going to answer based on what I configured my IDE to do, which is spaces. I specifically set up my IDE to use spaces. It would be utterly braindead to hit the spacebar multiple times at the beginning of each line.
Anyway, I use Vim most of the time, rather than language-specific IDEs. There are almost always Vim plugins for whatever language I’m using, and if not I still get my preferred formatting.
Umm… “beginning of each line”? I didn’t think even vim required you to do that. Yes, many people do (you can audibly tell when they do, even with “quiet” keyboards) press the spacebar four times to make an indentation. But any modern IDE only requires you to do it once (or tab once) for each layer of indentation you want.
Gonzol, that is the reason why I think the survey may have been poorly developed. The whole point between tabs or spaces is the character and not the key pressed. Basically there are these two arguments:
– Tabs consume less bytes and can be rendered in any size you need your indentation to be
– Spaces let you have more control over indentation in cases when you need a long line of code to be broken in pieces and maintain a nice and tidy read of the code
I’m confused on the second one how that would differ from tabbing. When I break a line of code for readability, I use the same tab-indention that I do for nesting so that it’s consistent and obvious for the next person who reads it. Having varying lengths of tabbing seems like it would be harder to read.
Gonzol, not varying lengths of tabbing, but varying number of spaces when you break a long line, for example a long if statement consisted of many “ors” and “ands” with parenthesis and so on, or when you want your String look in the code the way it will appear on the screen when running
[code]char *foo = (
“In”
“Don’tn”
“Seen”
“Yourn”
“Problem”
);[/code]
If ever something inside a pair of parenthesis needs to be broken into multiple lines, just break everything instead. If you would need to break and there are no parenthesis yet, just add them.
I prefer to use a brace style which does never need alignment on keywords identifiers. So if you need to break an argument list, everything gets on a new line, and then is just indented with tabs, no side effects.
If the style guide does not permit that, indent with tabs according to the current indentation level, and then use spaces to match the length of the non-tab characters in the previous line.
Both renders nicely regardless of the configured tab width.
Are you saying to tab/space to match the placement of the brace in the first line? In older styles, I could see that, but now that most are going to names that “self-document”, that’s too deep for tabbing.
So we’re not talking across each other, my thinking is:
Employee.Address.CreateNewAddress( city, state, zipcode,
streetaddressline1, streetaddressline2)
If I understood what you were saying about matching the length of non-tab characters in the previous line, you’d run into problems with:
Employee.Address.CreateNewAddress( city, state, zipcode,
streetaddressline1,
streetaddressline2)
EDIT: Forgot that I’m on the internet where spaces aren’t rendered…
If you need to break one, then break all.
Employee.Address.CreateNewAddress(
t city, state, zipcode,
t streetaddressline1,
t streetaddressline2
)
Yes, that is two more lines, but the indentation is unambiguous. Also non of the lines is even remotely approaching the length limit.
So much for my preferred style.
For the other option, the additional indentation to match the parenthesis only with spaces. In front of the spaces all the tabs used on the parent line. So effectively:
ttt Employee.Address.CreateNewAddress( city, state, zipcode,
ttt ………………………………………………………streetaddressline1,
ttt ………………………………………………………streetaddressline2)
That fits the appearance which many of these “manual space artists” try to achieve, while still correctly behaving with different personal preferences on tab width.
So then the findings are that developers who are familiar enough with their editor to know what is output when they hit the tab key make more than developers who aren’t.
Could you stop with the “them dumb, I smart” garbage? Everyone knows what their editor is outputting. Even if they don’t delve into the IDE configuration, the first time they backspace over a “tab” they learn whether it’s replacing them with spaces or not.
Apparently not considering the number of people saying spaces are slower.
And it’s not a question of dumb vs smart, it’s a question of knowledge or ignorance of things like tooling and issues surrounding maintaining applications worked on by large teams. Someone who hasn’t worked on a large codebase that has existed through several generations of developers may not care about mixed spacing because they’ve never encountered that pain. And I would expect people without that experience to not be pulling as high of a salary.
How does “people saying spaces are slower” conflict with what I said? People making that comment clearly believe the question has to do with what key is being struck, not what the IDE is producing. And we’re not saying it as a hypothetical “somebody out there might be typing spaces”, but from actual experience of having coworkers who, when they wanted to indent, rapidspaced. The slightly more hollow sound of the spacebar hit hard with the knuckle of a thumb several times in rapid succession is easy to tell apart from normal typing. There are also a lot that I’ve seen over the years who drop their whole hand down and four-finger the spacebar to get their line spacing.
I have worked with a codebase that’s older than me. I’ve also worked with code that had a mixture of spacing and tabbing in an IDE that didn’t convert tabs to spaces, and the only issue was the people who used an inconsistent number of spaces making their part of the code hard to read. If your spacing is consistent (which, frankly, it should be), then you can change between tabs and spaces arbitrarily with no significant effort. Just mass replace t with however many spaces you want and you’re in your space paradise. Just mass replace however many spaces your tabstop is set to with t and you’re in tab paradise. If you’ve got large blocks of inline text in the code that might be affected by tab/space differences, you need to fix that anyway so do it before the mass replace. The problem of arcane legacy code is the changing coding conventions of the past developers, not whether they used spaces or tabs.
I doubt that is too common (I have my caps lock key mapped to control, I don’t describe keystrokes using that key as using caps lock), but to the degree that it is, developers who see the question as one on which key they are pressing and not what character is in the code are also, by definition, less knowledgeable on maintaining code bases. It makes sense they would on average be paid less.
This is true until you hit version control, where tabs and spaces are taken into account by default. Fine if you don’t care about Github.
Exactly this. Mixed tabs and spaces cause version control issues, and create non-obvious, and impolite indentation issues when multiple devs work on files that contain them.
I would expect people that don’t know this to earn less.
Except that backspace goes back over whole indentation level regardless if it’s replaced with spaces or not. But yeah, I would be surprised if anyone didn’t knew what their editor is doing at such basic level.
In every IDE I use, shift-tab goes back an indentation level while backspace removes the previous character. What IDE are you using that overrides backspace to indention level?
And again, drop the “them dumb, I smart” garbage. You are being intentionally condescending when you say things like “I would be surprised if anyone didn’t knew what their editor is doing at such basic level” and that behavior only devolves conversations towards a childish slap-fight.
> This is indeed talking about typed spaces.
No, it isn’t. Experienced developers don’t think about the key they pressed, but the characters that end up in the text file. I have all manner of shortcuts.
The difference in salary here might correlate to developers who understand their tools, vs. developers who don’t.
Configure your editor right and there is no extra time. Also, spaces maintain consistent visual styling across development tools.
You’re missing a variable prob
Code and data are here, try it out! https://github.com/dgrtwo/tabs-spaces-post
And, dare I say it?, have a look at the `tab_space_survey` function in the sample code in `README.md` and consider the effect of tabs vs. spaces on that.
tab_space_survey is an object, not a function. I’m not sure what you’re referring to?
Sorry, I don’t know R and I didn’t read too closely. Whatever that thing is on the line starting
tab_space_surveythrough the line startingfilter(Professional.... (I am moderately sure that what one calls it makes no difference to how using tabs at various tabstops vs. spaces would change the indentation of it.)Use an IDE that will display code formatted however you want it and save it formatted according to whatever code style convention is in place. Or use a pre-commit hook to format it. Arguing over tabs vs. spaces seems like a waste of energy.
Finally someone said it.
But then, if I fork it, and my editor changes the formatting, the merge will overwrite random bits of code all over. It’s only a waste of energy if source control treats it as non-semantic, and Git currently doesn’t.
Depending on the editor used, tabs get expanded into 4 or 8 spaces (typically). So, tab-indented source code often shows up with unintented indentation – really ugly.
Maybe, a developer who doesn’t know or care about that fact simply doesn’t achieve the same reputation as another one who knows and cares.
> So… this is certainly a surprising result, one that I didn’t expect to find when I started exploring the data.
I really wanted to be the killjoy who says “you can’t just [play around with your data until you find a result you like][1],” but…
[1]: https://en.wikipedia.org/wiki/Data_dredging
> p-value 10^-10, so this is **still a significant result** even under highly pessimistic assumptions. That’s actually very surprising: You did sloppy statistical analysis and still managed to get a “good” result.
[2]: https://en.wikipedia.org/wiki/Bonferroni_correction
I’m aware of the statistical challenges of multiple hypothesis testing, and I’ve done mathematical research on the topic (check it out in Chapter 5 of my dissertation: http://arks.princeton.edu/ark:/88435/dsp01hd76s238c ). But I just said I hadn’t expected to find this result, not that this wasn’t the first thing I checked.
As it happens, I was interested in writing a blog post on tabs and spaces, and after first measuring the percentage using tabs/spaces/both the first hypothesis I tested was the salary difference. (Wouldn’t you?)
I made pessimistic assumptions in order to demonstrate the robustness of your result, not to criticize it.
Sure, but you did call it sloppy 😉
I wouldn’t because that doesn’t make logical sense… But as an interesting clickbait, it makes a lot of sense. Most people clicked it even knowing it is a clickbait and that is where you win. Good job.
your cynicism runs deep.
No, I’m being truthful. Seriously. I would never try to correlate space/tab with salary because it doesn’t make sense for me, but I see things way too logic and that is my personal defect. I really wish I could have this kind of business ideas like “I’ll make an article about this very polemic topic, so I will have more clicks”.
clickbait or no, the math is solid. and the author’s defense of their motivations holds up. was it published because publishers see it as clickbait or because the author intended it that way? chances are it’s an honest article with its placement decided by appeal. but your defensiveness and readiness to attack motivations lead me to believe you disagree with its conclusions, or at least are cynical enough to question the motivations of the author — which is why i mentioned it.
Maybe I was too harsh in using the word clickbait, but the thing is that it was an interesting marketing move to connect salary with some specific polemic topic.
The math is as solid as saying that people are allergic to hanging (as in “most people die when in contact with it, so people must be allergic to it”).
Let’s say, I agree with the conclusion (correlation != causation), but the article itself is not informative. It doesn’t add anything. It doesn’t give you more knowledge. But it is a smart way to promote the survey itself. For instance, I didn’t know Stack Overflow does this kind of surveys and I would like to be part of it in the future.
What is illogical about it?
Because it is assuming your typing habits could influence how much you earn. The real reason why the survey got this result is certainly not the tabs/spaces. If you want to know the real reason behind this, you should isolate the money variable and start checking everything else. You may find a pattern like other people said with examples like “big companies favour spaces and big companies pay better”
You tell me why relate money to a typing behaviour is logical. It is not logical. It is marketing. The only logic applied here was that it is an obvious bait for people to click in the article and comment about it. And yes, I was caught by it hehehe
I think the reason is that many people don’t understand the question. Because many people are just using tabs, and they are not aware of the fact that tabs can be composed from tab characters vs space characters. They will probably think like this: “Of course I use tabs, who would press space repeatedly instead of using tabs”
So, I split people into four groups:
1. People who uses tabs, and know about spaces/tabs topic.
2. People who uses tabs, and don’t know about spaces/tabs topic.
3. People who uses spaces, and know about spaces/tabs topic.
4. People who uses spaces, and don’t about spaces/tabs topic.
I expect groups 1, 2, 4 to answer tabs. Because of not knowledgeable people in group 4, since we can assume not having knowledge about an arbitrary topic statistically decreases the expected wage, tab answer will have a lower average wage.
“tabs can be composed from tab characters vs space characters. ”
No, tabs are composed of tabs. The tab _key_ can insert tabs or spaces, but a tab is a tab. It’s not “composed” of anything. When someone asks “do you use spaces or tabs” they aren’t asking what key you hit. They are asking what is in your file.
As @chipoverclock:disqus remarked before me, tabs have to be rendered, spaces do not. The length of a tab varies across platforms – I’ve seen it rendered as 2 spaces, 4 spaces and 8 spaces in my life time. This one time I beautifully formatted code in my IDE with tabs, which were the width of 4 spaces in my system. As soon as I uploaded it on gerrit, its ugliness was pointed out to me and I soon realised that because gerrit was rendering tabs as 8 spaces, none of my secondary indentation had any effect anymore. I’ve since learnt 2 things
1. Do not use tabs to separate pieces of code horizontally to a specific amount.
2. Do not spend time making cosmetic changes when the right IDE plugin/package can do it for you on the fly as you type.
I guess people who have abandoned tabs are the ones who were quicker to realise this than their counterparts in the same experience bracket.
Will you marry me?
I’d love to!
Just for the people reading this, he did not just say yes to a random stranger: I am not a troll, I am his girlfriend. XD
Leading whitespace tabs, internal line whitespace spaces, this keeps your formatting and allows your editor to size the tabs how ever it is configured.
And is a complete PITA for anyone else to work on ever. Only do this if you live in a silo, and have no Github account.
Not with an .editorconfig and a style guide. Every project has its own requirements, this is just one of those. Some projects may use tabs and some projects spaces, being able to manage either is more important. If I had to choose it would be leading tabs, allowing display choice for each developer.
It doesn’t keep your formatting. If I have a multi-line comment to the right of two lines of code (i.e., the code lines are to the left of the comment lines, sharing the same lines), the start of the comments will line up for only one setting of tab indent. (Not to mention the PITA of changing your tab stops on all your different tools. I don’t even know how to change it on GitHub.)
Thou shall not have a multiline comment to the right of lines of code. 🙂 That is the source of all evil indentation problems. Keep your comments either single line or above/below code. Or stop all this commenting trend, let the code speak by itself in freedom and glory! 🙂
If you follow these rules, you will be able to:
– use tabs or spaces and nobody would care
– change tab size as you like, for better reading without beeaking indentation
– convert tabs to spaces and viceversa without problems
Jokes apart, code should be formatted in such a way that it really would not matter even if you edited it with non-fixed size fonts.
While I agree with you that writing code that’s so clear it doesn’t need comments is always the first thing you should try to do, not all code can be like this. As for where they go, comments should go where they make the code most readable. Making readability a second priority to solving technical issues that arise because you want to use tabs instead of spaces is utterly misguided, IMHO.
Yes, I was really joking when I said “do not comment”, but really, writing clear comments with one simple principle (no multiline comments to the right of code) is a good habit, and I do that even when I use spaces and not TABs. I don’t like to count on monospaced fonts either and not to be able to convert my code to TABs eventually. Portable code is code that “could” use tabs, if needed.
Code can be pasted in places you didn’t plan and edited on editors you wouldn’t imagine (like an html textarea or even facebook, ugh!). Sincerely I think that someone that uses spaces because are more portable should comment in a portable way too.
And then he can revert to TABs because then there is no portability issue any more 😀 (joking here)
You claim you’re joking, but actually you’re not. That’s the issue with junior programmers: they think that there are rules that always apply. And usually the main thing driving them to this mistaken idea is their lack of experience.
I just picked the second page from a search result for “assembly language” and got this, and you’re claiming that turning that 15 lines into 26 lines where you can’t see the “does this” right beside the instruction is a better thing. Well, have fun with that. (But, of course, feel free to show us any assembly code you’ve written in the last five decades, or ever, that show us how it should be done.)
You need to get to level four (“proficient”) and realize that there are no hard-and-fast rules (especially of the type you endorse), and then you’ll be able to have a competent opinion on tabs vs. spaces.
Hey man, relax, chill out, if I say I’m joking, I’m really joking. Seriously nobody sane would write on an SO related blog post “Guys do not comment code” :D. At least there is no minus button here! I agree with you that there are no fixed rules and I totally agree with you that assembly does require this kind of commenting, and yes, no tabs there. Any language is different actually, I’m pretty sure also COBOL would be much better with spaces (please forgive me, I like this kind of humour). For the remaining 99.9% of programmers that write in procedural language… no really you are right, there is no fixed rule. Rules like “Don’t write comments like this” or like “Don’t use TABs”… stupid rules. You go on with your comments and spaces, I will keep my TABs, and comment my way that doesn’t break up when you use my code on your editor.
Anyway your point is clear and you are 100% right, I hope mine is clearer too now (“Do not enforce rules on me as long as my code doesn’t jam on your editor”?).
And thank you for calling me a junior, that didn’t happen for quite a long time, I really feel younger now. Haha maybe I’ll go grab my ZX-81 and put up some ’80s music now.
Peace and love.
Tabs as leading white space only, all other alignment spaces. Tabs stops don’t exist because there is only tab indent. Most editors allow you to set how wide a tab is, 2, 4, 8. Multi line comments by definition would span multiple lines and therefore couldn’t have code to the left for any line after the first. Any thing else would be multiple lines with single line comments.
Tab stops always exist: what you refer to as “how wide a tab is” refers to the tab stop settings. Tabs being “4 wide” means tab stops at columns 5, 9, 13, …. Note that the tabs are not a fixed width themselves; with a tab stop at column 5, a tab character in column three is replaced by two spaces when rendered in a fixed font, whereas a tab character at column 2 is replaced by three spaces.
And therein lies the issue. Consider two lines:
Two tabs, two printing characters, six spaces, two printing characters
Three tabs, two printing characters, two spaces, two printing characters
With tab stops set at every fourth column, the second set of printing characters lines up on column 17. With tab stops set at every second column, the second set of printing characters starts at column 13 on the first line and column 11 on the second line.
In your example I see where adjusting tab width could misalign items, but your example is trying to align internal line items across two lines that have different leading whitespace indents. This seems like arbitrary alignment and ignores the natural grouping that the indent suggests, where I believe only aligning items within their indent groups is reasonable to support.
You could change the third tab on the second line to spaces, which in itself suggests it is being aligned to the first line, I do this sometimes, however, I can see an issue where tools that modify leading whitespace from tabs to spaces or spaces to tabs might modify those spaces as well if they happen to match the current tab width.
“[I] could change the third tab on the second line to spaces,” yes, thus breaking the rule you explicitly made above (“Leading whitespace tabs”) and also breaking, I assume, your implicit rule that one should use tabs for the indentation used to indicate code blocks.
In the end, I can always find examples of good, clear formatting that breaks tab users unless they all agree to use the same tabstops, in which case what’s the point of using tabs, since that can only break things (when users don’t use the agreed-on tabstops), never help?
Tab-users defend themselves by saying, essentially, “live with formatting it more poorly,” though usually that’s couched in terms of “you must follow these rules” (implicitly even if it makes the formatting less clear). I suppose that’s one approach, but in areas I understand well I understand the purpose of the rules and aim to achieve that purpose, rather than aim to follow the rules.
As long as we’re coming up with ridiculous theories based on huge, self-serving assumptions, I’ll throw one out too. Maybe it’s that tab users aren’t as worried about minutia and seek a better work-life-balance rather than higher pay.
or are lazy.
Ahhh, but did you think that those ppl who use spaces are more likely to lie? 😉 😀
The comments that talk about the “waste” in repeatedly hitting the space key are a clue to the answer. I suspect there’s also a correlation between high pay and developers savvy enough to use a text editor sophisticated enough to require exactly the same number of keystrokes to indent using either tabs or spaces.
Yes. Low paid devs don’t understand their tools.
Don’t think i’ve ever used a text editor that didn’t automatically handle indentation, except maybe notepad. Are you saying that those (apparently) incompetent programmers who use tabs are all developing under notepad?
Its also directly correlating with shark attacks.
Not even attacks – just correlates directly with sharks.
So, now we need this correlated with Vi vs. Emacs…
WHAT IF PEOPLE WHO USE SPACES ARE PAID BY THE HOUR AND TAKE LONGER TO TYPE STUFF?
*meanwhile in normal editor/ide* [tab] -> 2 spaces so doesnt matter. 😀
Using notepad can take more time.
“The model estimated that using spaces instead of tabs leads to a 8.6% higher salary”
This is an exceptionally silly way to present the finding…
The finding itself is, IMHO, not surprising.
*Using spaces gives one finer control over exactly how one’s code is laid out and formatted; and people who care about that sort of detail are people who care about other details, and so make better programmers.*
I suspect you’d find the same sort of correlation if you tested for “number of spelling or grammatical errors per 1000 lines of code” vs salary. (Though that one’s a little tougher to test well because of people programming outside their native language.)
But the causality doesn’t run the other way. Just switching to spaces (while still not giving a damn about either EXACTLY how your code is laid our or EXACTLY how it behaves) isn’t going to make you a better programmer.
Wow that’s something incredibly pretentious to say, over something that’s essentially a matter of taste. There’s plenty of well formatted code out there that uses tabs, and likewise plenty of rubbish one that uses spaces, it’s completely unrelated to the quality of code
You misunderstand what he’s saying. He says straight out that code does not become better by using spaces nor worse by using tabs. The point is that better code is more likely to have been written by fussy rather than non-fussy developers, and fussy developers also prefer tabs over spaces, so you’re likely to see the two together.
Indeed
You’re making a straw man argument… exactly the kind of logical fallacy a tabs programmers make all the time… 🙂
I prefer spaces over tabs. Most editors convert the Tab to spaces, so developers basically indent pressing the Tab, but that just creates e.g. 4 spaces. No one is bashing the spacebar. So if I was asked what do I use – spaces or Tabs I would be confused, and I guess a lot of people did answer spaces (because the end result is space indented) but they do use tab to do it.
There are still people who manually indent?
For over two decades, I’ve been using editors which know when to indent. Or de-indent.
That’s why I think the survey is about the character you are commiting to your versioning system and not which key you actually press. even more because you don’t really need to press any key most of the time. You hit enter and it will go to the right level. close braces, it goes to the right level again and if it gets messy, you still have a command to tidy up your code.
“There are still people who manually indent?”
Apparently so, otherwise (a) there wouldn’t be people who set tabstops to something other than 8 and (b) this almost as annoying as emacs vs. vi (vs effing vim these days) argument about whether tabs or spaces are better.
Have fun with your Makefiles then.
If you’re willing to use backslashes and semicolons, Makefiles work fine without tabs.
My vim automatically inserts tabs if I’m editing a Makefile, otherwise tab is 4 spaces.
I don’t use Vim. I use a modern IDE that does the same but without the feeling of living in the 80’s.
You got me. I get paid more than you to write code I don’t know how to build…
I think any language that requires tabs is not part of the discussion. In the case of Makefiles, tabs aren’t just for formatting, they have a semantic meaning.
It seemed obvious to me that I was making a joke and that everyone would understand it.
tabs vs spaces is not a joking matter. This is serious stuff! 🙂
People are at war because of Vim vs Emacs! 🙂
All I can say is, when deciding about tabs vs spaces, THINK OF THE CHILDREN!
Wow, I never knew that the whole spaces/tabs debate was simply a misunderstanding between the two groups. As an EE student/hobbyist programmer, I legitimately thought that people who used spaces actually pressed space 4 times to achieve that. Based on these comments, it seems like the tab camp is arguing “Pressing the tab key is easier!” and the space camp is arguing “But spaces make for more consistent formatting (and we also press the tab key!)” Without discussing their underlying assumptions.
It seems to me that people who continue to press the tab key for efficiency’s sake, but also go out of their way to update their .vimrc or IDE settings to change the tab key to spaces for formatting consistency, are the kinds of people who would take more initiative in projects, be more thorough in their research, and simply have more random knowledge – all traits that would be rewarded with promotion and salary increases.
That’s it, Morgan. Even though the higher salary didn’t arrive my pocket yet hehehehe
Or it did and you’re base value is lower than you thought…. 😛
I can agree with the base value for a programmer here being low (South of Brazil), but if I’m above it, I’m sure it is not much hehehe usually the local companies don’t reward programmers for being good. They reward the sellers who could sell a product that is still not finished and then make us do extra work because the product was already sold.
amen to that, across all walks
spot on. reflects my thinking exactly.
Yes. This is it. Anyone who knows their tools pretty quickly figures out how to make tab insert two spaces. Anyone who operates in a team pretty quickly figures out that tabs help other people to read their code, and cause fewer issues with source control.
These are qualities of high functioning developers.
Yeah, but that knowledge is generally due to somebody pointing it out and then going looking for it. Most editors don’t have that as an easily accessible setting, and most people don’t just go looking at settings pages for fun.
Also, if you’ve ever worked on a team you know how useful comments can be, but good code commenting is still pretty rare in the industry as a whole.
> that knowledge is generally due to somebody pointing it out
Yes, I remember when it was first pointed out to me. The fact I was, and continue to be, in environments where I learn these things probably (at least for me) correlates to the direction of my career.
“Anyone who operates in a team pretty quickly figures out that tabs help other people to read their code, and cause fewer issues with source control.”
My experience is exactly the opposite. I’ve never worked on a team that used tabs that didn’t have readability issues between different people, unless everyone agreed to the same tab width.
What make you think people don’t know exactly how their editor works, and exactly how the file is stored? Tabs are variable when viewed with other editors. Almost every place I have worked in the last 30 years has forbidden their use. I have a variety of rc and config files that I use to customize whatever editor a customer or employer uses. The one place that insisted on tabs failed.
If you look at the rest of the comments on this article, most of the ones that talk about preferring tabs say something to the effect of “The reason I use tabs is because I’d rather hit tab once than hit space four times.” The ones talking about the number of bits a character takes up are the ones who also use spaces.
This reads to me as if the people using tabs, in fact, don’t know exactly how their editor works and how the file is stored.
I’d like that not to be true. *sigh* But I’ve been doing this long enough to have met a lot of idiots. OK, you win.
Most of the time I don’t even use tab. My editor indents my code automatically. I only need to use backspace to delete indentation. And there is the problem with spaces – with tabs you only need to press backspace once in most editors and it just works. With spaces… you have to click-click-click-click… and count the clicks so that you don’t end up with indentation that’s not divisible by 4 in my case.
I just got through reading this thread, and I don’t see what you’re seeing about “most” of the tab-preferring responses being confused people who think the key, not the character, is being discussed. You’re quite right that there are some confused people in this thread, but most of the tab-preferring responses I saw were people who perfectly understood that it’s the character being discussed (any response that talks about “But tabs let you set the indentation level that you prefer” is talking about the character).
It’s not a misunderstanding on most people’s part. There’s a genuine disagreement over which character leads to better / more readable code. And it’s a debate that has been going on for YEARS.
:+1:
I use the space key, but I have my IDE configured so that it inserts ⅛ of a tab character.
Beautiful.
Since you’re thinking ‘tab’ even though you use space, your boss will think about giving you a raise but will not in the end.
This is just terrible. Clearly you should have it configured to insert ¼ of a tab!
Did you check age? Salary may be different because one style was popular at a different point in history, so a different generation adopted it.
Elder people tend to earn more. It makes sense.
I would think job experience would catch that.
Age is unfortunately more credited than actual experience
i don’t think there’s a rational argument for keeping your base files indented with actual tab characters. thankfully most IDEs at this point afford you the option — yes i use the tab key (or more accurately my IDE indents appropriately for me based on context in most cases) but the resulting files are indented with spaces. If you’ve ever had to edit a file with mixed tab and space indenting that made sense in the context of the author’s environment but was totally messy in any other, you’ve probably come to the same conclusion — spaces are the only non-equivocal answer. it’s been a no-brainer for years now.
You’re comparing spaces vs spaces mixed with tabs, not the same thing.
Indentation is broken in both mixed tabs and only tabs in this case.
Tabs for indentation of code blocks are great because you can set your tab width easily in just about every editor (even ones that don’t have tab to space conversion features), and so everyone can choose a tab width setting that works great for them (mine is equal to 3 spaces). If you need to further align code (like lining up equal signs) you would just use spaces here, no tabs or mixture of tabs and spaces. This way the code will always carry both the indentation and further alignment properly between editors, and has the added benefits of user defined tab widths and slightly smaller file sizes.
The “further alignment” may or may not work properly depending on what you’re aligning and where. Code blocks unfortunately lose spaces in Disqus, but in your editor try:
if something# A long explanation
other thing# on these lines.
and note that the comment aligns only with 4-column indents, not with 2-column or 8-column indents.
Yup. This.
Don’t do that. Mixing TABs ans spaces. I use TABs, and my comments are either single line or stay below or above. Multiline side comments are totally ugly! And *those* break indenting, if you change TAB size, not the TABs themselves.
Telling a team of programmers not to do something that comes very naturally and is done by almost every programmer isn’t a particularly good solution.
Like telling them “Don’t use TABs”?
🙂
No, right, that’s done by only 50% of them (and the poorer ones, it seems), so alright!
Richard Hendriks needs to see this!
I think this is super mario’s fault, he put value on the spacebar with coins.
Wha? Mario jumps with the A button
I just found out that Mr John Daring Fireball uses tabs and that just makes me seriously happy that I use spaces.
intellij saves tabs as spaces… the data is not accurate…
This is possible in eclipse as well. It is just a setting on usability and the actual.
I think you misunderstand the question. The question isn’t about which key you hit in the IDE to indent, the question is about what character is in the file on disk.
Pretty much all IDEs and editors are configurable in this way.
Yes, I did understand that… the problem is knowing the default… and if it’s configurable what kind of data does this produce? imagine that only 10% of the developers actually change this setting then all the data here is actually 90% wrong or not accurate.
Been thinking, and the thing is that I’m also confusing this survey with an “old” news like this but that went through all the github code and there almost all of the code was using spaces… which indicates that the default on the IDEs is to save with spaces but yes, given that this is a survey on developers it might be right. sorry for the confusion…
As far as I can see tabs use one character code wheras 4 spaces use 4. So a tabbed file will be much smaller than a non tabbed file, so tabs rule.
Is this a joke? How far are you indenting your code?
If you’re in a language like Java and properly indenting, it’s pretty easy to have large blocks of code three indents deep. You can have blocks of code be much deeper than that (I once had a for loop end up seven indents deep).
So we’re talking up to 21 extra characters per line. Tops. Is that significant to anybody?
If you typed code all day, every day, for ten years, you might save a couple of megabytes by using tabs over spaces. Text files are not that large compared to say, image files, or video files.
I have been coding for years but I find it easier to press the tab key rather than the space key four times. I don’t think there is an option in dreamweaver to turn tabs into spaces anyway.