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.


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.


David Robinson
Data Scientist

Related Articles


  1. Andrew Gallant says:

    That extra salary goes towards paying off the extra effort it takes to use spaces instead of tabs >;o)~

    1. Franklin Fotang M says:

      Best comment!

  2. Fahad says:

    This only proves one thing. People who use spaces lie about their salaries.

  3. Farid Bonawiede says:

    Run this discussion with your team? Fork the discussion and have it with your team!

  4. swarchitect1 says:

    my hypothesis: the higher salary comes from their social skills. They take into account that different team members use different editors and only with spaces it looks correct on all of them.

  5. Yitzchok Ginzberg says:

    What about devs who hit TAB but have it set to expand into spaces?

    1. Ben Basson says:

      Who *doesn’t* do this?

  6. Robin Munn says:

    Evelina Gabasova has done a more complete analysis, and found that by simply looking at the median salary, your analysis was missing something. Specifically, the salaries of space-using developers had two peaks. The highest peak in the salary graph for spaces and tabs was right in line with each other: no significant difference. But there was a second, lower, peak in the right-hand half of the graph, where a significant number of space-using developers were clustered in a higher salary bracket, while developers who used tabs (or who used both indentation styles) showed no such second peak. Here’s the relevant graph:

    When Evelina Gabasova analysed the results further, she found that those developers who had higher salaries were strongly associated with three factors:

    * Using spaces for indentation, not tabs or “both”
    * Using Git for version control, not SVN or Team Foundation Server
    * Contributing to open-source software

    Read the linked article for more details, but it seems to me that the causal factor is probably somewhere in the “Contributes to open-source software” realm. I.e., people who contribute to open-source software tend to be more passionate programmers, and therefore tend to be more skilled, given the same number of years of experience, than their peers who don’t contribute to open source. And it also seems likely that most open-source software uses Git, and that most open-source software uses spaces for indentation rather than tabs. (The latter is my intuition, and would need to be verified — but it matches my experience). And therefore, if someone contributes a lot to open-source software, they probably have gotten used to using spaces, and also they probably have become better programmers than those who have only contributed to their employers’ projects (because they have acquired a wider breadth of experience).

    So apparently, it’s not that spaces give you a higher salary. It’s that contributing to open-source software gives you a higher salary, and contributing to open-source software makes you more likely to prefer spaces over tabs. And thus, the correlation is explained.

    1. Robin Munn says:

      P.S. She also mentions a correlation with using PHP, but never expands on it in her article, so I can’t tell the size of the correlation. I have therefore left it out of my analysis above.

  7. Nice one

  8. EddieTechie says:

    This is simultaneously both hilarious and intriguing.

    I’m surprised no one mentioned this scene yet:

    1. Anil Gulati says:

      See… she is right, and he IS wrong. Tabs will make a larger file size, but bytes don’t matter if the file doesn’t even RUN because of a different tab setting that screws consistent indentation in the interpreter. If you have a stable environment you can trust an expander to auto convert your tabs, but then he’s clearly not conversant with good practice because he expands his tabs to 8 spaces! It was really obvious something was wrong when confirmed he was using Emacs instead of Vim. She’s better off without him. The reason you earn more using spaces … is because spaces are BETTER.

  9. netplayground says:

    In the final analysis everyone is overlooking one thing: A space is simply a tiny tab. So, everyone prefers and uses TABS whether they are willing to admit it.

  10. Tejay Cardon says:

    Clearly the title is just backward. It’s really that higher paid (and therefore more talented) developers know that spaces are better. 😉

    (lest anyone start throwing rocks, I hope the sarcasm is evident)

  11. D. M. says:

    Statistics NEVER paint a false picture and unverifiable claims MUST be true under every circumstance. Every “data scientist” knows this.

  12. vurso says:

    Everyone knows you can leap further with tabs! #froggerlife

    1. netplayground says:

      apparently you end up jumping past GO and don’t collect $200.

  13. Catto says:

    David stellar article! Interesting how about the percent of amount of people using spaces & tabs are about the same at 41%. Also interesting about the salary difference.

  14. dreaddy says:

    Agressive people like to hammer on the space key to keep their focus.
    More agressive people get a better salary.
    simple… must be it 😛

  15. Ben Griffiths says:

    Clearly the survey respondents are fortunate enough not to be employed by nincompoops who reward them on the basis of LOC produced, and instead are getting paid by the character…

  16. malkia says:

    Please make a study comparing developers using arrays with base index 1 vs 0. It would be a fantastic addition!

    1. Jack says:

      Or, you could use a language that allows one to have the base index any integer! 😀

  17. Dan Harvey says:

    Being mostly a contractor I use whatever the local “code standard” is at the place i am working. 😀
    Good to know i can ask for extra if i have to use spaces lol.

  18. Konstantin says:

    Only millenials will know arrows and tabspaces can be brought together…

  19. Bysiur says:

    Or maybe those using spaces are less reliable and they tend to lie about their wages? 🙂

  20. laoinjo says:

    I knew it, Python was created to keep the salaries down.

  21. laoinjo says:

    Isn’t this due to what language you use? Cobold, C programmers generally don’t indent, and their average salary are higher than C++, C# and Java programmers. Also indention is more common in frontend languages than they are in backend languages, and backend developers are paid more than frontend developers…

  22. Dmitry Dziuba says:

    How you treated the problem that for all users, 42.9% used tabs and 37.8% used spaces, while in “provided salary” group numbers are correspondingly 40.7 and 41.8? It means that significantly more “tab users” hide their salary than “space users”, potentially leading to a misleading conclusion.
    Why hiding salary correlates that much with tab/space metrics? Were you able to identify some other abnormalities?

  23. MobsterSquirrel says:

    What about converting tabs to spaces? Do I also get more $$ in the end of the month?

    1. netplayground says:

      No more $$ and fewer free hours as well I would think.

  24. Oudamseth Samin says:

    Now, it would be more interesting to do a salary analyst for developer who use Mac vs Windows.

  25. Oohhh… so that’s why I’m underpaid!

  26. Steffan Perry says:

    Sure it has nothing to do with age? I.e. Old developers who are in senior roles use spaces, but younger junior devs use tabs?

    1. Jason Daniels says:

      I know many well paid senior developers who prefer tabs, for many of the holy war reasons. I also know plenty of junior devs who prefer spaces. So age isn’t a relevant factor. REASONS for use are most relevant, and not at all addressed by this poorly constructed survey. (i.e. The participants opted in, they ignored a statistically significant number of respondents. They only talked about medians, not how the distributions looked, and implied causation, a horribly irresponsible behavior for a statistician or scientist. A Data Scientist certainly knows better than either why these methodological errors are significant and mean this article was a waste of space.)

      1. forresthopkinsa says:

        Waste of space? That’s kind of extreme. I don’t think anyone is suggesting causation, but it’s *interesting* either way.

        1. Jk says:

          “Waste of space” pardon the pun

        2. Jason Daniels says:

          All he added to this myopic debate, was a spurious correlation. Causation was at least flippantly suggested at the very end. (“Though for my sake…”) On top of which, through his entire article, he actively fanned the flames of a debate with all the merits of arguing about putting pineapple on pizza, or forbidding such an act. (I’m in the forbid camp…) So yes. I stand by “waste of space.”

          1. forresthopkinsa says:

            lol, the “For my sake” was a joke. Goodness man, lighten up!

    2. Jacob Lynn says:

      This question seems to be addressed in the very first figure in the article.

  27. Nosferatu says:

    No offense, but don’t you thing that the tool used for development is responsible for the tabs, especially if you code in Python?

    1. Eugenio Rustico says:

      No offense, but have you read the text? 🙂

      1. Michael Bushe says:

        Sure wish they broke it out by language used.

  28. Jason Daniels says:

    Correlation is not causation. This article implies, certainly with the last statement, a causal relationship. As a data scientist the author is in a position to know better than to make such statements. It’s disheartening that he chose to do so.

    Furthermore, the reason I PREFER spaces is it retains the original presentational intent, readability and therefore comprehension.

    However, the cause of my better than industry median salary is not that I use spaces, but rather I think about why things are done, and stick with proven, measurably superior results. What is measurably superior than either tabs or spaces, for overall results is keeping coding styles consistent within a file, and application. This is far more effective than dogma (i.e. spaces and tabs both have pro’s and con’s). That means for the sake of a project, and my peers, I eschew my personal preferences so that other developers can stay productive by not having to reattune their brain to a different method of code formatting for just the parts I worked on.

  29. Pena says:

    What about whitespace programmers ( ). Are they all millionaires?

  30. beets says:

    Reading the comments, I’m beginning to think a big reason for the discrepancy is that less skilled individuals that actually DO use spaces will tend to answer ‘tabs’ because they press the tab key on their keyboard for indentation and don’t realise they should have answered ‘spaces’. This means those less skilled developers, instead of contributing evenly to each pool, actually are skewed towards ‘tabs’ and lower the average pay rate of ‘tabs’ vs ‘spaces.

  31. Neithan says:

    How about (me, for example) using 2 or 4 spaced tabs to prevent repeating keystrokes and let the code formatter convert it to spaces? Tabs are like variables; if my team wants to use 3 spaces per indent, I modify it and… ta-daa

    1. beets says:

      That’s ‘using spaces’.

      1. Neithan says:

        That’s not the key I’m pressing though. And way easier to navigate within tabs than spaces. And who wants to “clack clack clack…” with the space key?

        1. beets says:

          That’s the point, you don’t. You have your editor convert tab to space for you automatically. No-one (sane) actually presses spacebar for indentation…

          1. Klaus Busse says:

            Actually no one (sane) should do much identitation by hand anyway… your editor and your linter do that for you.

          2. Neithan says:

            I must be seeing plenty of crazy people from reputable youtube channels blasting that space key then.

        2. Félix Gagnon-Grenier says:

          Using spaces has nothing to do with the actual key you press, it’s about the actual character, or representation of character, on disk. Do you really believe all space users use the space bar?

  32. Tiago Celestino says:

    I started use to tabs in my actually work, but I keep using to spaces on my personal projects.

  33. Layne says:

    Love it! Glad Germany is closing this critical gap.

  34. emrah says:

    This means nothing. You can get any result from surveys. It is mathematical trickery.

    1. D Foster says:

      This article should be presented as a case study in how to lie with statistics.

      1. Dirk Durka says:

        You realize you have to actually back that statement up with a refutation based on the raw data, right?

        1. D Foster says:

          Were I making a case, and not merely stating my view, yes—that would be true.

          I suspect that most agree that the claim is silly enough to not need formal refutation. Those who do not will need to look elsewhere for that. I can’t claim to be that interested.

          1. Dirk Durka says:

            Ok well in that case, your original comment should be presented as a case study in how to lie without statistics 😀

          2. D Foster says:

            Or as a study in making an elliptical comment… and how one might be misinterpreted..

  35. Aleksandr Tokarev says:

    Big software companies enforces using spaces, because different tools displays tabs inconsistently by amount of white space, depends upon tools you are using you may dislike results. In case of spaces, results on screen independent of tools. Those developer usually have big salary. Be a developer in big company, you will use spaces, and get big salary.

    1. Youda says:

      That’s just misunderstanding the point of tabs. Every reasonable text editor and IDE offers an option to set the width of tabs. And some people preffer to have the indentation to be wider and some others to be narrower. Using tabs allows everyone to be happy WITHOUT CHANGING THE CODE, just by changing the settings. If all used tabs, the world would be much better place to code in! xD And by the way i work for quite a big company and we use tabs.

      1. Aleksandr Tokarev says:

        You sometimes restricted by tools. You not always have ability to watch on code via your favorite editor. When you do diff with company source control, or see history of the code those tools usually don’t have option to set width of tab. If you see code of other team via web. If do code review. On build machine you don’t have other tools except notepad, and usually you don’t have time to set settings if build failed and you need fix/resume. Of cause, when you write code you use your favorite IDE.

        1. Youda says:

          If everyone participating on the project uses the same indentation, there cannot be problem in diff. Moreover tools are improving over time, graphical extensions for git already allow to set width of tabs, browsers already allow to set width of tabs. Only people who use older tools will have problems with tabs.

          1. Aleksandr Tokarev says:

            People use tools, which they want incl. old, or new but without tab settings. Not all tools has tab settings, Sometimes they restricted to use a specific tool, which does not have tab settings, but tool is useful and integrated with dev infrastructure. And tab settings for all devs are different.

  36. Otto says:

    Ffs… Did you check their “age”?

    Older people use spaces, younger ones use tabs. Regardless of programming experience, absolute age is the factor here.

    1. Jordan Gray says:

      I didn’t know that! Is that one of the results from this survey? (I haven’t checked the raw data yet.)

    2. Dirk Durka says:

      Level of experience was controlled for. Provide data please.

  37. Beyond the tabs and the spaces, it’s pretty nice to see the difference (as usual) in anual salary in different countries.

  38. Srivathsa Kalale Nadaddur says:

    Quite a revealing fact. I use spaces, because i want to be in control.

  39. Y says:

    What was the salary of those who didn’t answer the question?

  40. Jon says:

    I think it’s this… the higher paying languages like Rust, Clojure and Go favor spaces, therefore those programmers even when programming in lower paying languages like JS and PHP still use spaces. Being generally higher paid is what skews things up and down the graph. It’s likely a Rust developer is going to do a little PHP on the side, or in the past, but is not going to take a 50% pay cut and switch to tabs doing it… It’s unlikely a PHP developer using tabs is going to do a little Rust dev on the side, or in the past, nor that they’d charge 50% more and switch to space if they did.

    1. Rogan says:

      lower paying languages, like JS? Don’t think you’ve seen the salaries a lot of JS devs get paid.

      1. Jon says:

        I’m just going by the data in the chart here…

        For what you’re asking you’d want a chart represented with ranges on each language, but that’s honestly extra data not needed for this chart to illustrate the point. There certainly are JS devs (and PHP devs for that matter) getting paid 100k+, while there are others getting paid < 25k. Being a very flexible languages they're not at doing the same things with it, but it is weighted toward the low end. Keep in mind the dataset source. This isn't scientific survey of the industry survey, it's a self-reported survey of stack exchange users. Welcome to fun with statistics…

    2. Except that Go favours tabs; it’s what gofmt uses which every vaguely experience Go developer uses to format their code.

  41. Ethuil UI says:

    I will be honest, tabs and spaces difference is so irrelevant in my mind, that I only realized what this article talks about half way trough. I was sure this is about difference when using workspaces or alt tabbing, thus tabs and spaces. So, yeah…

  42. Martin Ekelund says:

    Did you consider age in this? Maybe older professionals have kept their old habits using spaces… and usually they earn more?

    1. Patrick Günther says:

      But my gut tells me that older professionals would be more likely to use tabs, since they come from an era, when storage capacity was more expensive.

      1. Good point. As a note aside: some of us “old guys” often make the individual IDE auto-convert each single tab into several spaces on keypress. Spares you several keystrokes… and shows the “older generation” (read: 10+ years coding peeps) may still hug old habits, but it keeps evolving (whenever it makes sense).

      2. Jason Daniels says:

        While certainly affected by language of choice, “Tabs vs Spaces” is an age old debate going back decades, prior to my starting college in 1989. So I disagree with your gut feeling. I see it more as an extension of the “Which programming language is BEST” debate. Which, itself is born of the same mentality that pits Superman against any number of other Superhero’s in imaginary fights. (Clearly Sarcastro would win.)

        There is a lot of dogma on both sides. This debate still rages on in message boards today, and hasn’t really broken any new ground in a long time. This article was just another more of the same data point in that fray trying to use the allure of and easy, but totally bullshit, way to get more money to sway people to one manner of coding, instead of getting them to intelligently use their brains, the real cause of getting more money.

        In reality, the most effective way to program on your own is that which a) aligns with your preferences AND b) you can maintain easily at a later point in time. In a group, it’s that which the group can maintain with least effort at a later point. However…

        The more members on your team, the more consistency in the coding starts mattering more than any of the pro’s and con’s of any one approach. Furthermore, self-inconsistency always takes more time for people to process, comprehend and act on. (i.e. tabs and spaces used with no easily discernible reason for the change)

        It’s my opinion that the reason I’ve seen large groups implode when not just automatically enforcing a formatting standard on code check-in, is that you get divergent personal preferences. Trying to make people remember to code in manners counter to their brains wiring ultimately creates discomfort, and eventually strife in the group, which is never productive.

        If a tool does it for you before check in, you’re allowed the freedom to make decisions that align with your own preferences, without impacting the end codes consistency, on check-in.

    2. Jon says:

      He writes that he controlled for “Years of programming experience” which seems more relevant than age (lots of people start programming late in life and adopt the practices of new programmers regardless of age).

      1. Otto says:

        Typing is not programming, and how you type is influenced by absolute age and total experience typing, not only by experience in programming.

        1. Jon says:

          That’s Interesting point, but I’m not sure I follow the logic. What is the conclusion you’re drawing from “absolute age and total experience typing”? That those people would use spaces or tabs or just that it’s totally irrelevant?

          I can imagine the oldest of typers probably learned on mechanical typewriters where they likely used spaces for indenting… but by the time _anyone_ starts to learn programming it must have been a long time since those days.

      2. An0nym0usC0ward says:

        I wouldn’t say I’m a young programmer, with almost two decades of coding behind me. I prefer tabs. (And I’d also say I’m quite well paid, but maybe I’m just a statistic anomaly.)

    3. Félix Gagnon-Grenier says:

      From where does this idea of younger devs using tabs comes from?

  43. Rogerup says:

    LOL. I imagine people here know the survey is about the characters that is saved, spaces(0x20) or tabs(0x09). And not about the key which is pressed, which is the TAB key for most programmers (spacers or tabers). I can imagine that can exist a few programmers which press space a lot of times, but they are really a few.

    1. Bones Justice says:

      If there’s one thing the tabbers and spacers should be able to agree on, it’s that anyone who indents with the space bar is doing it wrong.

      1. An0nym0usC0ward says:

        Not really. If you go through the comments, you’ll find that some, although they know where the tab key is and what it does, actually press the space bar repeatedly – with pride! Given the many completely stupid things that often go on in corporations, it’s probably corporations where they fit in perfectly – hence higher salaries for space pressers.

  44. D. Michael Martindale says:

    It’s because developers using spaces don’t have to waste time scrolling right to see their deepest indentations.

    1. wzrdtales says:

      Most editors **and** browser allow you to adjust the depth that a tab has. So basically you can have an identically looking source file using tabs though. But spaces do have just a more unified representation, not suffering from user dependent settings and it does not matter if you view the code in your editor or on i.e. github.

      1. Victor Engel says:

        Exactly. Not just github, but many tools will default to a specific spacing for tabs, which may differ from what’s used in the editor. By the way, I don’t see an option for my use: using tabs and spaces, but having my development platform convert tabs into spaces. How the spaces are entered doesn’t seem that relevant. Having spaces in the code is more relevant.

  45. HalflingPony says:

    Until further evidence comes to light, I’m just going to assume that this is the result of the most productive programmers breaking the tab key on their keyboard from overuse and switching to spaces to compensate. 😉

  46. cminsanjose says:

    I am retired. I preferred spaces rather than tabs in the various languages and type of code I produced. Tabs cause indented code to move to the right too fast. Code scrunched up at the right margin not only looks ugly but is less readable.

    1. Constantine Kharlamov says:

      …unless you figure that there’s a single metric “indentation size” to which spaces and tabs should conform, effectively making them indistinguishable.

  47. MoreMozart says:

    I’ve been coding for over forty years, in that time I have used at least a dozen different editors. I use spaces for indentation, because tab settings have to be configured and may change when the editor changes, or if I am editing on a co-workers machine, or I am online using a client’s machine, or I use some software to print my code, or whatever. I don’t want to look up how to configure tabs to make my code look right.

    I rely very heavily on indentation to provide clues to nesting, in all languages (it is required in Python). Including in assembler. I like my code to look exactly the same no matter what software interprets the file. So I forced the habit of not taking advantage of any short cuts with a tab key. Spacing is second nature to me and I don’t have to think about it or count spaces or anything else. It produces consistency in the code and to me makes it easier to debug; in fact I consider bad indentation in my code to BE a bug, even if the compiler (or interpreter) is not affected by it. It is a bug in supporting the future maintenance and understandability of the code.

  48. Fields says:

    I don’t get how this sterile discussion can make its way into studies… It’s the same as discussing opinions… because it’s exactly that: opinions. And opinions are like ass holes: everybody has one. And how can one ass hole be better than one other? You’ve got much better studies to care for, honestly.

  49. Mustafa Atalar says:

    Here is my approach based on psychology: Tab users like/need more space, larger areas. Space users can see the same thing in smaller area. This state gives a clue about psychology of both type of users. Tab users probably need more time, more office space, and larger screen monitors and mobile devices, which means more cost for bosses. So they are not preferred compared to space users. If this approach is right, we have a new thesis: Tab users are more relax and happier people. So health costs are less, but bosses solve this issue with heath insurance. I also want to k now what is the condition of non indenters?

  50. Michael Hardy says:

    Among those who stated their incomes, incomes were higher among those who used spaces. But suppose getting a high salary and using tabs is correlated with not wanting to tell people how much you make. That would skew the results.

  51. Jim Sykes says:

    Should be obvious. The code monkeys are paid by the byte.

  52. A lot of this, at least as relates to open source, is largely driven by community standards. For example, the Drupal community has fairly strict coding standards that among many other things requires two space indentation. The result is a very readable codebase across the entire community. Those that don’t adhere to that standard will not have code accepted into the contrib space and thus will be less likely to be hired by folks like me (I’ve been around for 13 years in the Drupal world). That would naturally skew salaries.

  53. NumberMuncher says:

    28,657 survey respondents, apparently excluding those who answered NA. Within that group, you have exclusively defined subsets of 40.7%, 41.8%, and 17.5%. Then you mention a subset of 43.4%, which is fortunately where you focused your comparisons. Why bother telling us anything about those 16,231 who were excluded from further analysis unless you meant to compare them later?

    Anyway, sure this was meant to be more humorous than useful, but it might help if people knew why. these numbers say nothing about whether a person who suddenly changes to using spaces will make up the difference in salary any time soon. For all we know, a person who has been using spaces because they love them has a certain mentality which is favored over someone who has been using spaces for the same amount of time but only because everyone else wanted it that way.
    Maybe they skewed the numbers.

    Interesting to see that the slope of the Tab-users is less variable than anyone else. I see two inflections in the Spaces line, and one in the Both line.

  54. utsav says:

    Are we really discussing this? Dont we have code to write?

    1. Jevgenija Karunus says:

      Did you really write this comment? Don’t you have code to write?

  55. Sir_Brizz says:

    Now do this for word wrap.

  56. zippeurfou says:

    @disqus_2fRP1wjI8f:disqus I feel like the main reproach here is comparing the median rather than the distribution (using a proper statistical approach to see if there is any significance).
    I also added a similar chart for the IDE because some people were asking for it but I wouldn’t draw any conclusion from it as the sample size for some of them is really too low.

  57. Fields says:

    Well a recent study shows that developers using spaces cause about 8% rise in total costs of ownership with their IT due to larger storage space requirements. I use tabs because I care how much money my company saves from my responsible coding behaviour.

    1. Steven Noyes says:

      Study shows developers using tabs increase maintenance costs by 20% as other developers not using the same exact editor can’t read the source because of random indentation.

      Tabs should have been banned decades ago.

      1. H4X! says:

        i like tabs. tabs are my friends.

        1. Darren Collins says:

          That Shift key, though – total waste of time. 🙂

          1. H4X! says:

            you know it. lowercase and underscores only 😉

      2. Fields says:

        Good developers can’t get a good joke when they see one…

    2. hikingmike says:

      It makes sense to just use a single character (or byte). I use spaces since my IDE does, but I don’t know how this all evolved. It’s odd that everyone hasn’t coalesced to using the same method by now. I wonder if screen width had something to do with it, since wider screens are a relatively new development, and presumable 2 spaces would be nicer for narrow screens than tab.

    3. KlingOn2K says:

      Switch now before you go broke !
      Tabs will burn a deep hole in your pocket. I will soon be making a DIY video for Youtube on how to pry out the tab key safely from the keyboard once and for all.

    4. Jason Daniels says:

      please provide a citation.

  58. Eliott “ReDeathRay” Castafolte says:

    Thankfully my tab key is a macro to 4 spaces when I’m in my editors
    Also, my editor transforms tabs into spaces whenever I open a file so that’s that

    1. teejay_1987 says:

      Any code editor / IDE has that feature, not just yours…

      1. Victor Engel says:

        The data didn’t seem to control for this, though. I’d like to see a result for people who enter tabs but have their IDE change tabs to spaces.

        1. teejay_1987 says:

          I think that nearly no one enters 4 spaces manually (at least in normal conditions).

    2. The Drupal community uses 2 spaces, which, IMO, is easier to read. Multiple nested indentations with 4 spaces gets ridiculous quickly.

  59. Coinoleum says:

    People earn less because they are worth less. The insistence on tabs over spaces is a reflection of a poor attitude towards programming. A tab has several problems, most notably it can not be distinguished from a collection of spaces visually, without some aid, like an editor that marks them as spaces. They therefore render any semantic use of space problematic. Tabs also get interpreted variably for formatting purposes, potentially making code confusing, even when space is not semantic.

    Any developer who is not sensitive to these issues is probably not sensitive to other aspects of their code. They make code that has more errors, is inefficient, or hard to maintain as a result. Hence they will make less money.

    1. hikingmike says:

      Devil’s advocate: I don’t know if those tab problems you listed would matter much if everyone used tabs. You would know it’s tab just by looking. Unless the language you’re using has different meanings for tab and space other than white space, which could also have been prevented if everyone used tabs when the language was created.

      1. Richard Hussong says:

        The problem with tabs, even if universally used, is that a tab does not always represent the same degree of visual spacing when interpreted by different programs or devices. It is not sufficient for everyone to use tabs; they must also set up all programs and devices that interpret tabs to interpret them the same way, something that may not even be possible. The great virtue of spaces is that, assuming fixed-width fonts, they are always displayed exactly the same way.

        1. hikingmike says:

          All right, that’s true

        2. Christopher says:

          But if everyone used tabs, doesn’t the degree of visual spacing become a non-issue? Assuming the code is idented, it’s still going to look fine.

    2. u8y7541 says:

      My editor marks tabs so I can clearly see them.

  60. Bill.Linder says:

    Can we just say linter? I do not know about most other developers, but I use a linter for all coding. Said linter auto formats my lines, catches typos, logic errors, misspellings and other Stupid Human Tricks (SHT) we all do. I do not need spaces or tabs. Less format focus and more code focus. Surely I am not the only one.

  61. Booligoosh says:

    This could be because more professional developers use modern editors like Eclipse that convert the tab key into spaces…

    1. R says:

      Eclipse sucks. I use vim/neovim and it has all features of a modern editor.

      1. AutoSniper says:

        Can you set conditional breakpoints and do you have an associated debug console?

        1. Are you trying to say you don’t know how to “set conditional breakpoints” and/or debug your code without “an associated debug console” some IDE provides? #ShiversRunningDownMySpine

    1. NumberMuncher says:

      I think that’s why the blogger decided to “leave them out of many of the remaining analyses”. Most of them didn’t survive the first round of questions.

    2. Tim Locke says:

      Tabs only for indenting. Spaces for separating tokens. Using tabs or spaces to align comments is silly.

  62. AmagicalFishy says:

    This seems a little contrived, mostly because I think the simplest explanation wasn’t addressed. That is: Developers who use spaces instead of tabs are generally better developers. (Perhaps it’s because “developer skill” is a difficult thing to measure?) This doesn’t mean that using spaces actually has any kind of effect on your salary. In that same way, better cooks probably have more cast iron—but getting cast iron isn’t going to actually affect your cooking skill.

    1. Steven Noyes says:

      I think it has lots to do with experience. TABS are okay when you are a one man band and you never change toolsets but then… BANG… you are in a team and people are using different tools/editors and the TAB becomes a serious liability with sharing work product.

      1. Darren Collins says:

        These are exactly my thoughts.

  63. Arduenn says:

    I use tabs, but my editor always converts them to spaces.

  64. Gustavo Bandeira says:

    Yes, but if we use spaces, US will spend more on science and we will have more deaths by hanging, suffocation and strangulation!

  65. Rolf Howarth says:

    I just wish a text editor somewhere had adopted the only sensible way to format code: ALWAYS use physical tabs at the start of the line, one for each level of indent (and set your display tab stops to be 2 or 4 space or whatever you prefer) and NEVER use tabs at the end of the line when you’re aligning comments vertically.

    Regardless of what you type, the editor would never save a file with spaces before the first non-white space character, and never save tabs after the first non white space character. Trivial to implement, and that would solve all tab problems forever for everybody 🙂

    1. Robin Munn says:

      The problem with that approach is that you often want to line up parameter blocks:

      int someFunction(string firstParam,
      int secondParam,
      SomeClass thirdParam)

      If you use tabs to line up those parameters, you’re going to mess up the alignment. (See for details if you don’t yet know why “tabs for indentation, spaces for alignment” is the ONLY sensible way to use tabs in your code). Therefore, if you’re using tabs, you need to be able to use a mix of tabs and spaces in the secondParam and thirdParam lines: tabs up to the same level of alignment as “int someFunction”, and spaces thereafter.

      Which, in turn, means that your editor MUST be able to understand your language’s syntax. Which is extremely non-trivial.

      I would actually prefer tabs, as many others do, if they actually worked. But because it is almost impossible to get the necessary tabs-and-spaces mix right, and almost every editor gets it wrong, I end up preferring spaces because they’re the only thing that actually works, and lets me stop worrying about whitespace as I’m writing my code.

      1. Symbiatch says:

        I use tabs and I never worry about whitespace. Why? Because it’s irrelevant. I don’t need to line up parameter blocks or anything. I write code. Editor indents and makes it as it should be. That’s it.

        But I guess this is the reason why people use spaces: overly obsessing about things that don’t really make much of a difference. And I’m the one with loads of OCDs. Fortunately not this one.

        So people should try it sometimes. Just code. Spend your time pondering how to solve the problem and implementing it rather than stressing about alignment of parameters or comments. Might help 😉

        1. Suragch says:

          What is your salary?

        2. Steven Noyes says:

          Sounds like the some of the coders on my current project. I fail a code review in less than 5 seconds and give it back to them because blocks don’t align properly and they respond: “It’s only white space and doesn’t impact the comment.” So it gets failed again.

          Alignment maters for long term maintenance.

          1. Robin Munn says:

            Alignment matters for long term maintenance.

            YES. You will read code many times more often than you write it — so take the time to make it readable. You will be a lot happier in the long run if you do so.

      2. Nick says:

        I use tabs for indentation and spaces for alignment, one of my plugins for visual studio handles it for me automatically. Best of both worlds.

        1. Robin Munn says:

          What plugin do you use? Because I’d love to find a plugin that does the right thing here:

          »---if (someLongFunction(firstParam, secondParam) == "Arbitrary value"
          »---....&& someBooleanConditionThatAlsoHasALongName)
          »---»---Console.WriteLine("No braces around this line");

          Above, »— represents a tab character (set to be four spaces visually since that’s what I prefer), and …. represents spaces (as it happens, four spaces since that’s the number of characters in “if” plus a space plus one parenthesis).

          I would expect something as sophisticated as, say, Resharper to get that right (and as far as I know, Resharper does get that right, though I don’t have my work machine in front of me to verify that). But unless the plugin knows how to parse your code syntax, you will either get two tabs on the second line, or one tab + four spaces on the third line, neither of which is the correct result. And since I’ve never found a plugin (short of Resharper) that did the right thing in the rather-basic use case of a simple if statement split across two lines, I find that “tabs for indentation, spaces for alignment” is not practical for me. Yes, it’s ABSOLUTELY the right approach if you’re going to use tabs at all. But since I don’t want to be made to care about whitespace, and just want to get on with coding, I have to use spaces-only since that’s the only one the editor won’t screw up.

          So which plugin are you using that does “tabs for indentation, spaces for alignment” correctly? That sounds like a boon, and I’d love to check it out.

          1. Jerry Barrington says:

            Since you do that sort of aligning, you *already* care about whitespace. Nobody has to “make” you care.

          2. Robin Munn says:

            Perhaps I was unclear. What I meant to say was that I don’t want to have to pay nit-picking attention to which characters I’m using for which section of the code. I care about the two parts of the if statement being lined up; I do NOT care about which characters are used in lining them up. Except that if one of those characters is a tab, then I HAVE to care, because the editor won’t do it for me. And that is why I prefer spaces, because it allows me to not care which characters I use. (Unless there’s a plugin that will actually do it *right*, but so far I haven’t encountered such a thing. Hence my request to Nick).

      3. NumberMuncher says:

        Tabs allow users to vary the apparent depth of the indentation for legibility. They can be used when a block only needs aligned with other blocks on that same level of indentation, or when alignment is trivial.
        Use spaces when alignment is not trivial.
        Sounds like more environments need to be more flexible to that.

        Anyway, anyone who bothers too much with aligning whitespace anywhere other than at start of line is silly. Those alignments are more likely to change if code is tweaked or added or revised.
        Comment blocks should never be tacked on the ends of lines — but that’s how I work.

  66. Marc3488 says:

    The “confounding factor” is simple.

    The question was: “Tabs or spaces?”, with options: “Tabs”, “Spaces”, “Both”, and “NA”.

    The majority of professional software developers use some sort of Environment (aka IDE) in order to be productive. I don’t suppose it’s too big of a stretch to imagine they use _modern_ IDEs as well.

    The vast majority of modern IDEs I know of will default to spaces for code indentation. If you hit TAB, it’ll just insert (usually 4) spaces in your file for you.

    When these professional developers were responding to the survey, they answered “spaces” because technically, that’s what their code is being indented with. It all comes down to defaults.

    I don’t claim ALL of the difference is accounted by this fact alone, but _most_ of it is for certain.

  67. Goyllo says:

    One simple question to SO developer? Is this survey make sense at all?

  68. Pacerier says:

    My understanding is that spaces are more Efficient because code is easier to read when compact (aka indentation hell).

    But there’s a problem with the analysis so far: you controlled by country instead of controlling by location (city).

  69. What are you trying to say? And what advantage do I get, as a developer, from reading this nonsense?

    1. Dauve says:

      What he’s trying to say is that developers called Billal are more likely to take a humourous light-hearted blog post incredibly seriously

  70. Infiyaz Khalid says:

    If you considered multiple countries, how did you standardise salaries? A person earning USD6,000 per month in the US is the same as someone earning USD2,000 in India due to the lower cost of living.

    1. AutoSniper says:

      They never said anything about standardizing salaries.

      1. Infiyaz Khalid says:

        Then it is wrong to compare the salaries in their raw values against different countries.

  71. D B says:

    That’s not why tabs were created in the first place. They were created to reduce bandwidth when printing reports over slow lines, like 110 or 300 baud. They were not flexible as they were, initially, fixed to every 8th column.

    1. Victor Stafusa says:

      No. They were created for typewriters and later ported to computer keyboards.

      1. D B says:

        Gosh. I guess I didn’t use typewriters much when I was initially coding. I did use Teletypes and ASR33s though. Which had fixed tabs. Unlike typewriters.

    2. Pacerier says:

      Citation needed.

      1. Steven Noyes says:

        Citation? Sounds as if D B, like me, lived this. Life? On slow serial based printers with 110 baud links you could only communicate 10-12 characters per second and printers could print fast than that. So TABS were used to speed up the communications of the data from the computer to the printer for forms and source code. Changing TAB stops, while theoretically variable with set horizontal TAB (ASCI 136 I think), was almost never used because it was not very universal and TAB stops were almost always alined on 8 characters columns. Vertical tabs were always 6 rows.

        This could cut your print time by 40-70%. It was significant on slow serial printers.

        Then the PC came and editors (like Borland’s Turbo Pascal) started allowing control of on screen indentation levels and TAB usage but every editor treated TABS differently. It became a mess and we are still living the nightmare.

        1. SomeArchitect says:

          This is true. They were used to make printing more efficient, but they were created to assist table entry with typewriters.

          From WP so take with a pinch of salt.

          He’s right when he says further down that they didn’t have fixed tabs, but tabs were clearly invented and used by typewriters then co-opted later for use in printing for compression.

  72. An0nym0usC0ward says:

    Tabs are obviously more flexible than spaces for indentation, and indentation is why tabs were created in the first place. Only, especially in large corporations, there’s always some furniture police at work favoring strict rules, most often conventional and without meaning, often counter-productive – such as spaces for indentation. Devs being willing to accept such brainless rules will work in large corporations in a larger proportion than devs having little tolerance for BS, and thus be better paid. That’s my take on it.

    1. Victor Stafusa says:

      Tabs are a mess. Their size is highly context-sensitive and varies wildly from project to project and even within different files in the same project or even in different parts of the same file. Also, reading code idented with tabs in e-mails, browsers (like in github) is a painful experience. Having to define and redefine what the heck is the size of the tab over and over again is hell. To make things worse, many people mix spaces and tabs carelessly and don’t know how to properly ident the code, yet they produce code which you as a programmer will need to rad and/or mantain. IMO, THIS is counter-productive!

      1. An0nym0usC0ward says:

        Nope. Tabs are not messy, as long as you use them exclusively for what they are meant: indentation. Using tabs for spacing too, or mixing tabs and spaces is indeed messy.

        You do not constantly redefine what size a tab is. You define it once for an IDE/mail reader/whatever, and then you always see everything indented the way you like, not the way the mail sender/another programmer likes.

        Go have fun looking over some code using a one space indentation level, or one using 16 spaces for a tab. With tabs, you don’t get to see such a thing, with no additional effort whatsoever. With spaces, there’s no way around reformatting everything.

        Look at it another way. You never press the space key repeatedly to create indentation, you use the tab key. What’s it to you, if there’s a tab inserted or spaces? The only real difference occurs when code is shared between programmers using different indentation sizes. Spaces force everybody to look at code the same way. Tabs don’t – they’re more flexible.

        Also, people who don’t know how to indent code, or don’t care to properly indent code will make a mess regardless of whether they are using tabs or spaces.

        Modern IDEs are making this a no-problem, anyway. Just format the code to your liking, and that’s that. Smart teams/setups have a version control hook to reformat to one unifying convention anyway.

        1. Victor Stafusa says:

          “Spaces force everybody to look at code the same way. Tabs don’t” – That is exactly the reason why I use spaces. If I write code in some way, I would want that other people would see it in exactly the same way as I did when I wrote it. When somebody else writes a code, I would want to see it in the exactly way that the author saw when (s)he wrote it. I see no reason to do otherwise. I don’t want to lose time trying to figure out what should be the tab size, specially when working on multiple projects with different settings, because, frankly, I have no time to lose on this stupidity.

          Also, by browsing code in github, or receiving diffs on e-mails, there will simply have no IDE support whatsoever, and it would be better if I never needed it in the first place.

          Further, by “format the code to your liking”, that would be good in projects where there is only one person coding or if all the members perfectly agree with the formatting rules and are extremely zealous to not break them. Unfortunately, that is rarely truth for large projects – many developers are sloppy and we all need to interact with their code.

          I am personally already tired of getting git marking files as conflicted because somebody messed with identation rules.

          I am also already tired of getting cases where the same file is formatted half in one style and half in another style, possibly rendering it unable to be fully sanely presentable in any tab-size setting. By reformatting them, I risk to produce more git conflicts if any of my coworkers also change the file.

          BTW, checkstyle has a module to forbid tabs: – and of course, if everybody was zealous and attentious about formatting rules, nobody would need a tool like checkstyle.

          And yes, I do press the space bar repeatedly if the IDE or whatever text editor I’m using don’t translate tabs to spaces automatically.

          Finally, it is common to have restrictions on line widths, and those are harder to be respected if people are free to set their tab-size to whatever they want.

          1. An0nym0usC0ward says:

            Essentially, what you are saying is that you would like to enforce your view on how code should look on everybody else, and that you are tired of other people having different preferences than yours, and that you’d rather dictatorially enforce one convention alone, than try to find a solution that fits more than just you.

            Checkstyle … it’s enforced on one of the project’s I’m currently working on. It enforces javadoc comments, for example. But it is easily fooled. Guess how those comments look like, and how meaningful they are, in non-library code. That’s exactly the kind of stupid, furniture police like rules I was talking about.

            If you press space bar repeatedly, instead of properly setting up your IDE, you’re also of the opinion that programmer productivity should be measured in lines of code. Right?

          2. Robin Munn says:

            Isn’t that precisely what code style guidelines are FOR, though? ALL the projects I’ve worked on professionally have specific code style guidelines so that the code written by coder A and coder B will look the same.

            So yes, having the project lead “enforce [his] view on how code should look on everybody else” is precisely what should happen. If the project lead has chosen to dictate spaces for this project, use spaces. If he has chosen to dictate 4-space tabs, use 4-space tabs.

          3. An0nym0usC0ward says:

            The coding guidelines I have worked which have also made sense were prescribing things such as making local variables and function parameters final/const, the order of public/protected/private declarations in a class body, naming conventions and the like. Only a small part of them was dedicated to actual formatting. Even so, after many years of programming, I found that such guidelines are more often than not an unnecessary cost.

            But here’s the fun part: all were defining the indent size in one single place, and then defining further indentation-related rules only in relation to that that already defined indent size. Aside from potential violations of maximum line length, nothing will happen when using tabs instead of spaces, in relation to such bodies of rules.

            And here’s a funnier part: you pick some open source library, using two spaces for indentation, to customize and include in your project. You occasionally merge from the public git repo, since it’s only a small part that you need to maintain differently, but you do want to keep your code up to date with upstream. Only, your project uses four spaces for indentation. Good luck keeping your code properly formatted across the entire codebase. I’d rather spend time on something else than checking and fixing indentation after each pull – avoidable if using tabs for indentation.

          4. Robin Munn says:

            Yes, that is a case where tab indentation is theoretically preferable to spaces, though there’s a trivial solution: EditorConfig. Configure that file to be 2-space indentation (you ARE keeping the 2-space indentation bits in a separate file, right? You’re not copy-and-pasting, are you?), and the editor plugin makes sure your edits in that file are kept up-to-date. And since you really should be using EditorConfig anyway, it’s not really an extra cost.

            But while in theory I agree with you that tabs would solve that problem, in practice I have nearly always found code intended with tabs to create more problems than it solves, because almost nobody actually uses tabs correctly. I say “nearly” always because I have seen precisely ONE project in my whole life that both: a) used tabs for indentation, AND b) did not suffer from mismatched-tab alignment issues anywhere in the project. (It was a two-man project written in Python, and if I could remember the project’s name, I’d cite it, because the authors actually Did The Right Thing™ and I would like to praise them publicly for it). All other projects I’ve ever seen suffered from mismatched tabs, even more often than the mismatched-space indentation that you mentioned. And if people were careful about only using tabs for indentation, and using spaces for any necessary alignment past the indentation level, that would be great. But in practice, almost nobody seems to get that right, so tabs result in an even bigger mess than spaces.

            So yes, in theory, I would like to agree with you and use tabs for indentation and spaces for alignment. But in practice, that just results in ugly code. At least with space indentation, you NOTICE when someone else has used a different indentation level than your default, and you can temporarily switch your indentation to match theirs. (You’re NOT going to put 4-spaces indents into that 2-space file when you edit a couple of lines, right? And you’re NOT going to reindent the whole thing to match your preferences, right? Both of those are *terrible* ideas.) And better yet, EditorConfig can do it for you.

            Trust me, I’ve been there, seen that code, got the misaligned T-shirt. All too often. And at the end of the day, spaces are the only way to ensure that you don’t get that T-shirt.

          5. An0nym0usC0ward says:

            Your experience is different from mine. For many years I worked in a team that used tabs (and Allman, by the way), and everybody was very conscious about formatting. Now I work on a project where there’s one guy (highly appreciated) who is whole-heartedly against tabs, and who doesn’t give a rat’s behind on formatting. We also have checkstyle integrated in the project, guess what the effect is …

            If I take some other code and want to integrate it in my project as source code, not as a precompiled library, I’ll also want it to conform to my project’s coding style. For such reason I have encountered more than one project which stayed with ancient versions of code they took from a library many years ago – distinct formatting made merging of fresh versions a pain.

            Tabs vs spaces is a technical matter. Sloppy vs orderly programmers is not a technical matter. They are orthogonal.

          6. Robin Munn says:

            Tabs vs spaces is a technical matter. Sloppy vs orderly programmers is not a technical matter. They are orthogonal.

            VERY true. Sloppy programmers can mess the indentation up with either tabs or spaces. If your team is doing indentation right and being careful, then tabs will work well for you. I’m glad you have such a team! (Well, except for that one guy…)

            Your second paragraph is a perfect illustration of why I find it unwise to integrate “foreign” files into your project in a way that changes the style of those files. I think it’s wiser to just put a comment at the top of the file saying, “This file comes from (name of open-source project) and is licensed under (license). It uses 2-space tabs because that’s what that project uses; do NOT change the indentation in this file to match the rest of the project.”

            Then if you ever edit the functions in that file, you make sure those edits use 2-space tabs, and K&R style (or whatever it has), and only in the files that you originated do you use 4-space tabs and Allman style. And you update your .editorconfig file to set up the rules for that particular file, so that you don’t have to remember to change your editor settings constantly as you switch back and forth between files. That gets you the best of both worlds: you don’t have to fiddle with your editor settings all the time, but you can still integrate any future changes to that file without running into tons of Git conflicts.

          7. An0nym0usC0ward says:

            Good luck maintaining the checkstyle configuration, so it does not check the files from the foreign project you integrated but does check the ones you modified. (I for myself consider integrating foreign code this way plain stupid, and not worth doing. But I don’t get to always call the shots.)

            I’m not necessarily arguing for the absolute superiority of tabs. In a well maintained codebase in the hands of a disciplined team, using a modern IDE/editor, they’re almost 100% equivalent. If a team feels they like spaces more, I don’t have a problem with that. Only, I consider that all other things being equal, tabs are absolutely equivalent, except for added flexibility.

          8. Robin Munn says:

            Since I haven’t used checkstyle before, I hadn’t thought of that problem. (I have been working in a .Net shop for the past decade, and have only ever worked on one Java project, in a different job. And that was back when I was a complete newbie so I wasn’t allowed anywhere near the build config at the time.) But a quick Google search turned up, which suggests that you can exclude files from checkstyle pretty easily. If that’s the case and I’m not missing any subtle problems, then it shouldn’t be too difficult to keep the original formatting from a file you pulled in from a different project, thus solving the Git conflict problem.

          9. An0nym0usC0ward says:

            I never said it’s not possible. Only, as time goes by, you keep changing additional files. You either keep all the files you got from outside with a different format, and exclude all, preventing checkstyle from checking even the files you modified, or you keep fiddling with the checkstyle condiguration as you change additional files or the structure of the code in the foreign project changes. Neither is an optimal solution, IMO.

            Repeating myself: I think taking over a foreign library’s source code and modifying it in your project is so costly it is in most cases not justified. The more so since most libraries lending themselves to something like this also have reasonable extension points, and, if something is missing, the devs are more often than not willing to accept push requests. But I’ve seen it done, repeatedly, and it’s cumbersome at best. You really have to sell the effort to either very many customers or to very well paying customers, to make it worth, and even then it either slows you down or makes you use obsolete code, once code ages and you stop pulling in fresh versions.

          10. Nick says:

            “When somebody else writes a code, I would want to see it in the exactly way that the author saw when (s)he wrote it.”

            I don’t, the size of a tab is am a personal preference. Maybe you like 2 character indentation, I prefer 4, I want my IDE setting to control that which tabs do perfectly. The issue is where people use tabs for alignment, that is a massive no. Spaces always for alignment.

          11. Steven Noyes says:

            That is great for languages not allowing you to break statements over multiple lines of code. As a result, if you use TABS, they have to be used for both indentation AND alignment and it simply does not work reliably between different toolsets.

            I suspect the pay difference comes from experience and developers with more experience have learned the evils of working with TABS in source files. NOTE: yes, some toolsets, like make, require TABS but that is a different discussion.

        2. Steven Noyes says:

          The problem is every IDE and editor STILL treats TABS subtly different forcing EVERYONE on a team to use the same exact editor to satisfy the needs of the one person thinking TABS are a good idea. Having the VCS do reformatting of code on a commit is simply a bad idea.

          1. An0nym0usC0ward says:

            Using tabs for anything else than indent is plain stupid, and developers doing so are wrong. As far as indent goes, there’s really not much that editors could handle differently. Indent is indent and that’s it.

            I haven’t worked on a team using the same editor/IDE for years now. We never had any indent problem caused by this.

          2. Desy13 says:

            Using tabs in the first place is stupid and shows that you are just a fucking noob

          3. An0nym0usC0ward says:

            I see. Your language and profoundly logical argumentation, on the other hand, clearly picture you as a very mature and level-headed person …

    2. Steven Noyes says:

      Tabs are worthless for indentation outside of one man band wanna be programmers. Once you need to work in a team of more than one where different editors might come into play, TABS have to be thrown under the bus because they can make code unreadable and seriously impact productivity.

      That’s my take on it.

      1. An0nym0usC0ward says:

        That is pure speculation. I have worked on countless projects using tabs for indentation. We didn’t have any formatting problem. I now work on one using spaces for indentation, and constantly have to remind committers that their negligence re. indentation breaks the build due to how checkstyle is used.

        When developers with different preferences for indent size look at the same code in their IDEs, a web page from github or elsehwere, they are forced to see it as the original writer of the code wanted it to look, not ow they’re used to look at code. This makes them less productive. If tabs are used, each one can configure his own IDE to his liking, and look at code the way he’s used to. This impacts productivity positively.

        Given these facts (i.e. not speculation) I’d say your statement is more of a religious than of a fact-based, rational kind.

        The only argument for spaces instead of tabs that’s in favor of spaces, presented in this discussion so far, is that messy developers make a mess when tabs are allowed. That’s a non-argument – sloppy developers make a mess when tabs are forbidden too. The only advantage of tabs is that everyone can configure the tab size to his liking, something spaces can’t provide. There’s really nothing more to it. There really isn’t anything making spaces better than tabs.

        1. Desy13 says:

          Dude, you are an idiot. The only projects you likely ever worked is creating a php website for your grandma’s retirement home, because no serious company will hire you if you rape their code-base with tabs.

          Spaces look same. EVERYWHERE. Tabs don’t. They look “okay” for one, crappy to “other” and totally shitty for the “third”. Idiots like you, cause billions of damage due to low productivity

          1. Bryan Oakley says:

            I really don’t think name calling makes for an effective argument.

      2. Bryan Oakley says:

        I think saying “seriously impact productivity” is a bit alarmist. Lets be honest, a few misaligned tables or blocks of code here or there isn’t going to matter a whole lot. Still, given the choice between a few misaligned blocks and no misaligned blocks, I’ll chose the latter.

  73. macartisan says:

    I use NO-BREAK SPACE just to mess with the browsers.

  74. Commentor says:

    Nobody but the person who sets up the project should ever have to decide, because we have EditorConfig now. EditorConfig exists so the who-cares people can coexist with the we-care people. BUT… the problem is that the who-cares people don’t even care enough to install the plugin. It’s like knowing you can’t spell and refusing to use a spellchecker.

    1. Redge says:

      And some with a spellchecker will add words with incorrect spelling because they thought the original was wrong!

  75. Colm Bhandal says:

    Here’s a potential confounding factor. It relies on the fact that this correlation is just between what people answered to the survey, not necessarily what they do day to day. And people answering surveys tend to do so very quickly. What if the wording/positioning of the tabs vs. spaces question had an effect? For example, the word “spaces” is longer and has an extra syllable vs. “tabs”. Maybe the question said “What method of indentation to you use?” and the first answer was the lovely short “tabs”. Lazy people might have simply clicked on “tabs” without reading on. And it’s not hard to believe that laziness correlates with lower salary in the IT domain, where pedantry is rewarded.

    I’d like to see the actual survey, or a screenshot of that question if anyone has it? If indeed the question is phrased as “lazy person bait”, we have a potential confounding factor on our hands: laziness. We can’t tackle this confounding factor in any way other than actually reissuing another survey, with a question that’s purposely designed not to let the above happen. A lazy-proof question would be needed. Of course, all this is dependent on the wording of the actual question, which would be really interesting to see…

    1. Pacerier says:

      What’s the technical term for this bias btw?

    2. andrewarchi says:

      The question, according to the survey results, was “Tabs or spaces?” and the response options were “Tabs”, “Spaces”, “Both”, or “NA”. If they were ‘lazy’, then they would pick “NA” because it has the shortest character count

  76. Leyendlink says:

    Python LOL

  77. Molly Carpenter says:

    This analysis is problematic because it doesn’t account for cost of living differences that vary wildly in a country. A developer in San Francisco, CA doing the same job as A developer in Portland, OR would be paid more, but will likely not be living as well. The use of spaces and tabs broken down by region may behave similar to dialect differences between those regions. So those highly paid developers in San Fran may prefer spaces because everybody they know uses spaces and may be surprised that anybody uses tabs. I have a feeling that when one digs deeper it will be revealed that space vs tab use has little to no cause and effect relationship to “standard of living”. Gross vs net.

    1. Archibald McNeill says:

      In what way would the cost of living have any effect on this? It seems that you’re going down the path of saying that there are some regional influences on whether a developer uses tabs or spaces, but somewhere along the way you try to tie in the cost of living in that region, which is completely unrelated. Your hypothesis would mean that for some reason, developers using tabs or developers using spaces would group together regionally, which has no backing unless you have some knowledge of their grouping that I don’t.

      I do however think that you’re on the right path in questioning the validity of this blog post. To me, it would make more sense if developers that use spaces were skilled in technologies that provide higher salaries. What would contribute to the higher space usage is if we found a correlation between technologies with higher salaries and the syntax with those technologies requiring spaces (or the education for those technologies encouraging spaces). That’s my two cents, anyway.

      1. Molly Carpenter says:

        If you can keep more of your money you live better. Have the opportunity to save more and retire sooner. So getting paid more doesn’t help if most of that money is eaten by expenses.

        1. Aaron Shumaker says:

          That would only have an effect on the results if there was a bias of people in different areas with different cost of living. E.g. if it were more common for people in high er cost of living areas to also use more spaces. It’s like saying, but what if all the people using spaces also get robbed daily by muggers on the street? We can reasonable assume there wouldn’t be a proportionally greater number of space users getting robbed than tab users.

          1. Molly Carpenter says:

            A lot of our tech workers are in places like San Francisco and Seattle which have high cost of living. Also by extension higher crime rates.

          2. Aaron Shumaker says:

            Yes there are people in different crime and cost of living areas. The point you are missing is that is an independent variable. It doesn’t corelate to space/tab usage. Reread what I said about “bias”.

            You are essentially claiming that if I live in a low income area, that I go to work and say to myself “Hmm, my rent is cheap, so I will use tabs.” and someone else goes to work and says “I pay alot on my rent, so I think I’ll uses spaces”.

          3. Molly Carpenter says:

            Well I was leaning more toward space/tab usage being regional and how cost of living varies with region.

            I also saw a comment where somebody mentioned that space usage may be more tool related than anything. A lot of the respondents are working in web development and the tools tend to be hostile to tab usage.

            The data could be saying that web developers are getting paid more. It also could be saying that more web developers use stack overflow.

            The article implies getting paid more means living better. There simply isn’t enough data to determine if usage of tabs or spaces is really better for one’s bottom line.

    2. OllieJones says:

      Ms. Carpenter’s observation points to an obvious question to ask of the data.

      Do the spaces and tabs people belong to different subcultures? Do the space cadets hang out at different bars and meetups and coffee shops from the tabsters? If there’s a big NYC or Mountain View cluster of space cadets, it could skew the stats.

  78. Sudhir Jena says:

    Somewhere I get a intuition that programmers who use spaces also constitute those who copy paste some part of code from public sites like github and codepen. Due to copy paste, managers conclude that they are more productive and hence highly thought of but such programmers are assembling software not crafting it. Programmers who craft code would use tabs most of the times.

    1. not sure says:

      Why would that be the case? What makes you think that… While some copy-paste programmers will get futher in certain companies, they are usually the ones with bad managers and shitty pay. Which is why bad programmers can sneak by as ‘good ‘.

      1. An0nym0usC0ward says:

        You’d be surprised.

        Especially in large enterprises, managers of software developers do not understand what writing code is about. It’s magic to them. They’re constantly surprised that it actually takes time, and that it can’t simply happen at the touch of a magic wand. They constantly suspect that developers are cheating, and that their estimations are beyond what time is actually needed.

        Such managers, having no clue about code, tend to look at signs that are relevant for a worker’s value in other fields, but which are more often than not bad in programming. You’re valued if you do overtime. You’re valued if you write many more lines of code than your peers. You’re valued if you’re constantly hitting your keyboard, rather than take breaks and stare mindlessly at the monitor. And of course, you get a better pay.

        I always say that in software at least larger companies are a way more convenient harbor for stupidity than smaller ones (but I have a suspicion it’s the same in other domains too). A small company cannot afford unnecessary costs. In large companies a source of unnecessary cost, such as an industrious programmer never thinking his code through and spending more effort on coding than necessary, may never get booted. A small company will quickly discover that what he delivers is more costly than what apparently lazier programmers, who take more time to think than to type, and boot him. Plus, large companies inherently are more prone to a higher density of stupidity – stupidity infiltrates everything, and there must be a constant effort to weed it out. Only, larger companies move slower, due to sheer size, and as a consequence stupidity has a naturally longer survival time there. This makes people with low tolerance to BS move away from corporations, leaving them with the more stupid folk in the labor marketplace. But it also means that BS-intolerant devs will on average get a lower payment.

        1. Félix Gagnon-Grenier says:

          That is some convoluted bs right there…

          Welcome to 2017, where companies such as the ones you describe are slowly dying, and where the new sexy is having open spaces, time for reflexion, thinking, planning, challenging ideas.

          Welcome to 2017, where managers understand necessities of the internet, the dangers involved with online piracy, and the paradigm of programming.

          I can only wish for you to leave that sour space and see the new world, because what you seem to see right now is depressing.

    2. ondrej h says:

      I use only spaces and I have never copy-pasted code.

      1. Molly Carpenter says:

        Not even your own code?

        1. Bryan Oakley says:

          I’m the same way. I don’t copy/paste code. I don’t use any sort of snippet manager, or have a file of commonly used chunks of code. Those commonly used chunks are in my head.

          Naturally I will sometimes copy and paste my own code, but even that doesn’t happen all that much. I write reusable components, but I tend to avoid literally duplicating code.

      2. An0nym0usC0ward says:

        There are many situations in which copy/paste of tiny snippets makes sense. For example, when I have to provide an overloaded version of an already existing method, I always start with copy and paste of the declaration line. When I implement an interface, I sometimes prefer to copy its body rather than let the IDE generate the methods in the new class for me. I often copy setup code from one test to another – having extracted private methods for setup in tests introduces coupling and makes tests a lot harder to read. If you don’t do such things, you’re not optimally productive.

  79. camainc says:

    [ the sound of hundreds of underpaid developers quickly changing their IDE to use spaces instead of tabs ]

    1. Bob Hope says:

      [ the sound of hundreds of managers quickly standardizing on tabs instead of spaces to cut costs ]

  80. m2OnLin2 says:

    A key group is missing: those who use neither a tab nor a space. I expect those make the most.

    1. Adrian Smith says:


    2. Kyle Strand says:

      Erm. What spacing would that be?

      1. Alexander Simes says:

        New lines only, ha ha ha

    3. Suragch says:


  81. External Carrier says:

    What about the fields of activities of the companies?
    I would compare IT related company VS non IT related because non it companies pay more and are less likely to demand tab from there coder than IT companies are.

  82. Ender Localhost says:

    My point of view:

    Age it self and not experience might be a contributing factor.
    At least where I live there are a lot of older pople that due to the change on the job market over the past decades were forced to change from other lines of work to areas that are related or closer to IT and technologies. Some of these even ended up at IT jobs becoming IT technicians with less experience than others.

    This means that a lot of people dispite their lack of experience already have higher salaries because they already gave a lot to the company where they work at. And from my experience older people tend to use less shortcuts on computers.

    I understand that this might be too specific to explain the reason why people that use spaces earn more…
    But my point is to show that there probably are a lot of other contributing factors to this that are not taken into account here.
    So before we jump into a conclusion as the title on this article states we should probably dig further…

  83. Charlie says:

    The ALGOL heritage of the Bourne family of shells is particularly clearer with spacing, and unfriendly to tabs.

    This is far easier to read:

    if [[ $x == $y ]]
    then a=$b
    else a=$c

    Than is this:

    if [[ $x == $y ]]; then
    a=$b; else a=$c; fi

    The effect is magnified with deep nesting of control structures.

    An efficient developer is both clear and terse. Tabs are not friendly to these goals.

    1. Molly Carpenter says:

      if [[ $x == $y ]];then

  84. hikingmike says:

    What about an IDE that uses spaces, but you can hit tab to add 4 spaces?

    1. Yuval Gnessin says:

      This. I struggle to understand why the tabs vs spaces debate continues when it’s practically been solved by our tools.

      1. Kyle Strand says:

        The person I know who most strongly endorses tabs does so because he likes the idea that anyone can choose any amount of per-level indent they wish without modifying the actual file. This is of course impossible with spaces, where everyone sees the exact same layout (assuming monospace font).

        I don’t believe that this hypothetical advantage is actually that useful in practice, and in particular it wreaks havoc with any attempt to do vertical alignment between rows where one row has non-whitespace characters. Nevertheless, I at least understand why the idea sounds appealing.

        1. thisisthelist says:

          I think it actually points out one of the big problems with usage of Tabs that aren’t auto-converted to spaces. Code files that retain tab characters inevitably have items spaced with *both* tabs and with spaces. When the tab-to-spaces equivalency is changed from one dev to another, stuff that was nicely lined up for one developer becomes a misaligned mishmash for the next.

          1. Kyle Strand says:

            Yep. The fact that this happened continually on our project failed to persuade this particular developer, though.

          2. thisisthelist says:

            Funny how that goes. At this point though, a divide between tabbers & spacers seems so petty when I’m just hoping the U.S. somehow narrowly avoids a self-inflicted nuclear holocaust over the next year or two. : /

    2. Robin Munn says:

      Every time the tabs vs. spaces debate comes up, someone misunderstands it to be about which key on the keyboard you hit for indentation. It’s not. It’s about which characters are inserted into the file when you hit the Tab key. (Or which ones are removed when you hit Shift-Tab, or backspace when the cursor is sitting at an indentation level.)

  85. mithlond says:

    My wild conjecture:

    – spaces are easier to represent uniformly and consistently when rendered on the web (or anywhere else; a space is always a space, whereas a tab’s width is context-sensitive)
    – use of tools that present code on the web (github, BitBucket) has increased in recent years
    – companies, clients, and developers who try such tools and see their benefits are more likely to adopt them
    – use of such tools generally makes developers more productive, so they either get more freelance work done or command higher salaries than those who tend to use older, less-productive tools/workflows

    Or maybe the trendsetters and decision makers at companies that pay more are inclined towards Spaces for some other reason, so more skilled/valuable developers seeking those jobs are forced against their will to desert their beloved and far-superior Tabs. 🙂

    1. Bing987 says:

      That’s the whole point. Tabs may be faster, but spaces impart consistency to the code. No matter what display or operating system is used, the code looks right.

      1. Kyle Strand says:

        What do you mean by “tabs may be faster”?

        1. Bing987 says:

          Really? I have to explain it? Okay, a TAB takes one key press and 4 SPACES takes four key presses.

          1. Kyle Strand says:

            Um. That’s just not true. I don’t know of *any* modern editors that can’t be configured to insert spaces instead of tabs when pressing the tab key. Since tabs take up a variable amount of space, a variable number of spaces is inserted, corresponding to the number of character-columns that tab would have taken up.

            No offense, but there are several other comments in this thread that mention this fact, and even some comments mentioning how weird it is that some people who promote tabs don’t seem to understand that editors can insert spaces instead of tabs using the tab key; I was wondering if this was kind of a straw man, so I’m somewhat surprised to see that this is apparently the first you’ve heard of this editor feature.

            Since your previous comment indicates you understand the value of indenting with spaces, I hope you’ve found this discussion helpful, now that you know your tools can help you more than they apparently have been!

          2. mithlond says:

            I use Atom, and that’s exactly what it does when I hit the Tab key: it inserts the number of spaces I’ve specified as the “tab” width in settings.

          3. Bryan Oakley says:

            very few people actually press the spacebar four times. We use the tab key like everyone else. Most modern IDEs and editors Do The Right Thing when you press the tab key, entering the appropriate number of tabs, spaces, or tabs and spaces, depending on the configuration.

          4. Robin Munn says:

            Really? I have to explain it? Okay, a TAB takes one key press and 4 SPACES takes four key presses.

            Every time the tabs vs. spaces debate comes up, someone misunderstands it to be about which key on the keyboard you hit for indentation. It’s not. It’s about which characters are inserted into the file when you hit the Tab key. (Or which ones are removed when you hit Shift-Tab, or backspace when the cursor is sitting at an indentation level.)

    2. Kyle Strand says:

      Out of curiosity, since you recognize the consistency benefit of spaces, what do you like about tabs?

      Are you familiar with the idea of elastic tabstops?

      1. mithlond says:

        I dislike tabs, actually. The “beloved and far-suprior” was tongue-in-cheek 🙂

  86. jsphpl says:

    Surprisingly, no decision trees or linear models are needed to predict a flame war by the title of a blog post 😉

    1. mithlond says:

      The click bait monster just ate your lunch break nom nom nom!

  87. Fragile Development says:

    Correlation ¬⇒ Causation, but interesting correlation over a large dataset nevertheless, which adds weight the the correlation a benchmarking company such as BlueOptima find with 36 metrics over 6.4bn data points:

  88. Victor Sergienko says:

    “We need more pirates. When we had more pirates 200 years ago, climate change was never an issue.”

    1. mithlond says:

      Or, for purposes of this discussion, a more relevant example:


      On a more serious note, though, if it turns out that neither is causal to the other, can it be safely assumed that a third factor is causal to both?

      1. Nurf says:

        Yeah, my bad. I get cranky when people complain my CSS isn’t working in Internet Explorer 2.

    2. Victor Stafusa says:

      Your example could be answered by “the economical/industrial (r)evolution of the world made pirates obsolete and unfavorable economically, while that increased the emission of greenhouse gases which lead to climate change”.

      However, the problem here is exactly that they didn’t found such explanation for the phenomena. They tried a lot of them (countries, programming languages, etc), and it remained a mystery. Nobody here is telling that it has a direct causation.

      1. Victor Sergienko says:

        Well, the variable is not in the dataset. Everything else is a speculation.

    3. hikingmike says:

      Right, so we can ask the question – what is it about those developers
      that makes them more likely to use spaces and also more likely to make
      more money. Both of those are attributes of the same developers, whereas the pirates thing is about pirates and climate change.

      John Dibling has a valid theory below.

  89. Enrique says:

    What about the ones who only use command+alt+F?

    1. Kyle Strand says:

      What is command+alt+F?

      1. thisisthelist says:

        [F]lushes the code down the toilet.

  90. Victor Villas says:

    I’d suggest correlating with a more specific question: do you change de default indentation behavior from your IDE?

    I find that most people just want to hit tab and modern editors will decide. Most will even detect if the current document uses tabs or spaces and will automatically comply. So people who uses tabs nowadays are either because they work on a project and have to adhere, or are the ones that are *really* in favor of tabs.

    Because lots of space indenters are just going with the defaults, I’d say that the actual factor here is being someone who’s mindful against default settings is correlated with smaller teams and lower salaries.

    1. Bryan Oakley says:

      I changed the default indentation of my editor (emacs) about 30 years ago. Haven’t needed to change it since 🙂

    2. Michael says:

      This is what I was thinking too. I’m glad I don’t have to write out a full comment now.

      1. Michael says:

        I don’t think that default IDE settings plays a very big part, though. It probably just has to do with whether you’re contributing to a codebase that has its own convention about indentation (usually 2 or 4 spaces), or writing your own code.

  91. G. B. Versiani says:

    Spaces vs tabs is a matter of style. Tabs never format well enough if not all developers use the same editor, or agree with the tabs width.

    So, opposite to what has been said about laziness, people using spaces may tend to have more discipline than tab ones, even more if working in a team. These guys tend to follow strict code styles, including “lint” tools to avoid common mistakes. Personally I never read a new code indented with tabs which was as good as ones with spaces… But this is a personal assumption and in order to affirm anything about quality vs indentation, I would need to make an extensive research.

    Matter of fact, correlating non related data may be dangerous. It can lead to… some correlation! For instance, you could have related salary with drinking coffee/tea… What’s the conclusion? Does it matter?! So drinking a better coffee will raise my salary? If I suddenly start to use tabs then I will have a drop in my salary?…

    Maybe more useful correlations: working remotely vs. salary (approach being adopted by several companies), amount of space amenities vs. code quality (companies associate good space to work with productivity, is it?), etc.

    1. dodekeract says:

      Tab width doesn’t matter for “formatting well”. What matters is that someone who prefers 4-wide indentation doesn’t annoy someone who prefers 2-wide indentation. Next you’ll want to hard-code the syntax theme too, right?

      1. G. B. Versiani says:

        No my friend, this is not what I mean. Remember that usually programmers have to deal with the code width as well… So people who uses 8 spaces for tabs will get in trouble if the code was created by one which used only 2. Things get a bit less problematic for 2 and 4 spaces, but it’s there too.

      2. ondrej h says:

        It doesn’t really work that way. I often review code and the web tools we use (and are very popular) have a fixed size for a tab. Therefore I would have to get used to given width anyway.
        Also, what about pair programming?
        What really matters is to stop dealing with this pseudo-problem. If someone gets annoyed, it’s not the problem of the rules, it’s a problem of the programmer. If someone is too used to a specific style, it’s their problem. Consistency is more important than personal preferences.

  92. Cullen says:

    I use spaces but prefer tabs, due to working in code bases that included multiple languages with multiple developers all using different indentation settings. It’s very irritating to try to understand indentation when part way through a function the indentation level (two spaces – four spaces, etc.) changes. If developers configured their IDEs to represent tabs as different levels of indentation (two-space tabs vs. four-space tabs) and used tabs, they could each have their preferred code style on their own system, when viewing code they wrote or code someone else wrote, but that’s not the standard anymore. I haven’t encountered any professional here in the states that uses tabs in a professional capacity.

    For the few that do you use tabs, they are likely also working with employees that prefer spaces, and very possibly even working in an org that universally prefers spaces, yet they continue to use tabs. I use spaces cause it’s the standard, and I value coordinating with people smoothly more than writing code exactly the way that I want. This mentality tends to lead to more forward progress and better relationships with co-workers and managers, which also leads to more promotion/better recommendations to another job. It’s a balancing act to touch into the details of code and come back out of them when needed. You have to do both, and if you’re the extremely detail oriented kind of person such that you can’t give up certain details, you also likely are more of an introvert or more argumentative, and likely have poorer relationships with coworkers, leading to lower pay, whether you’re more talented/skilled/valuable than them or not.

    If you’re getting into arguments with coworkers about spaces vs. tabs, you’re probably doing it wrong. You need to stuff your pride (or maybe more idealistic outlook, whichever it is) and get to a point where you can coordinate, even if that means making minor styling sacrifices. There’s only so detail oriented that’s worth making a stink over, and the worst form of indentation styling is mixed tabs and spaces within one code base. Both forms of indentation “break” if they’re mixed with each other.

    1. dodekeract says:

      > I value coordinating with people smoothly more than writing code exactly the way that I want.
      But then, why do you force me to view code [2,4]-wide instead of [4,2] wide? Other people’s preferences are one of the main reasons why I always used tabs. I used to prefer 4-wide indentation and I was fully aware that most people can’t stand it. Therefore, I used a variable-width character.

  93. G. B. Versiani says:

    Spaces vs tabs is a matter of style. Tabs never format well enough if not all developers use the same editor, or agree with the tabs width.

    So, opposite to what has been said about laziness, people using spaces tend to have more discipline than tab ones, even more if working in a team. These guys tend to follow strict code styles, including “lint” tools to avoid common mistakes.

    Personally I never read a new code indented with tabs which was as good as ones with spaces… But this is a personal assumption and in order to affirm anything about quality vs indentation, I would need to make an extensive research such as the presented one.

  94. David Reed says:


    Size of “work team” may cause spaces rather than tabs to be preferred in code maintained by a group (who may have diverse tab stop preferences, ..

    Size of “work team” also may be causal with salary, because you need extra engineering skill to be highly productive when working with others closely.

    If you have proxies for work team size, it would be a good test of this hypothesis to look at correlations between space-use and team-size, and between team-size and salary.

    1. dodekeract says:

      > who may have diverse tab stop preferences

      Isn’t this an argument for tabs? Let the guy who prefers 2-wide be as happy as the guy who prefers 4-wide.

  95. Carlos José Bercero-Castillo says:

    Spaces people only care about money, not code cleaness nor professional development.

    Did the survey asked for how many job hops they had or how often their code gets turned back by QA? I bet spaces would double tabs.

    Tabs people focus their energy on doing things right regardless of their salaries, while Spaces on seeking better job opportunities that pay more and tolerate mediocrity. That explains this.

    1. mechler says:

      I agree that tabs are “doing things right” in the most pure sense, but the rest of this is just conjecture that amounts to being just plain mean. Good luck with this attitude. We have data to examine; let’s explore the real information for the answer.

      As an example, the guy just after you offered team sizes as a possible correlation through team-size being causal (possibly) with salary.

      1. dodekeract says:

        It’s a good point though. If you don’t care about your code you’ll just go with spaces since that’s historically used everywhere.

        1. Victor Stafusa says:

          I saw just the opposite. People who don’t care about the code will hit tabs because it will ident automatically (not paying attention if it is right or not). Also, people who don’t care tends to have a huge mess of tabs and spaces mixed with no pattern whatsoever and either don’t even acknowledge this (they are all invisible space) or if acknowledged, don’t care about it.

    2. G. B. Versiani says:

      No, using spaces have nothing to do with making money neither with mediocrity, or committing crimes…

      It is only an statistical conclusion: using spaces are related to better salaries. All the rest are just conjectures…

      In order to tell about mediocrity/bad coding vs. indentation, you need to show a statistical conclusion in this direction.

    3. Bart Van Leeuwen says:

      Indentation has zero to do with code cleanness, and everything with readability for humans. As for professional development, the numbers do suggest the opposite, as do the coding practices in every company I ever worked for. Rather, it very often seems people who militantly advocate tabs are stuck in a highly theoretical world with little consideration for the practicalities of the real world.

    4. Doktor Jones says:

      Just as the decline of US oil imports from Venezuela explains the decrease in pedestrian deaths from collisions with heavy vehicles or buses!

  96. John Dibling says:

    Interesting. I have a hypothesis. I use spaces myself, and have for many years – but I didn’t always use spaces. I used to use tabs, way back in the day when I only programmed for Windows. Later, I as started to branch out in to other operating systems such as Linux and embedded hardware, I switched to using spaces. Simply because spaces played nicer with a variety if IDEs and editors than tabs did. I still hit the tab key, but I configured the IDE to translate that in to spaces. So my hypothesis is that maybe there is an apparent correlation between spaces and salary not because using spaces mean more money, but the reasons why programmers use spaces. Perhaps programmers who use spaces have more experience across a broader domain of hardware and OS’s, and that breadth of experience brings with it a higher salary?

    1. dodekeract says:

      Meanwhile I have the opposite experience regarding IDEs/editors.

      Take a non-configured `vi` or `nano` for example. They force you to use 4x space to indent 4-wide in spaces but just work with the tab character as expected.

      The only major annoyance is web browsers due to their special “tabbing through forms” stuff.

      Other than that, I found that editors need “more work” to support tab -> space expansion. E.g. you need a better editor (even windows notepad supports tabs!) or a plugin.

      I’ve programmed on all three major operating systems for at least 2 years each. I used CLIs, IDEs and editors. Other than web browsers everything was harder for spaces users.

      1. Mike Richman says:

        We get it: you prefer tabs.

        But come on… no professional programmer is using vi unconfigured, or nano *at all*, right?

    2. Robin Munn says:

      That’s my theory as well: the more experienced a coder is, the more likely he is to have seen code edited by multiple coders with different tab settings, who didn’t think about their whitespace and just pressed the Tab key as many times as necessary to get this set of parameters / comments / whatever to line up on their screen. For example, I’ve seen code files where there was NO tab setting you could choose that would make all the vertically-aligned parts of the code line up, even though the original coders had clearly meant for these parameters to line up with each other, and those comments to line up, etc. But whether you set your tab settings to 4 spaces, 2 spaces, 8 spaces, or even *gasp!* three spaces (*reaches for smelling salts and fainting couch*), one part of the file would line up vertically but another part wouldn’t.

      There are only TWO ways to fix this problem:

      1. Tabs for indentation, spaces for alignment. has more details, so I won’t duplicate them here.

      2. Indent ONLY with spaces.

      Both solutions 1 and 2 will solve the problem. But solution 1 has a drawback: if I use it, now I have to pay careful attention to which whitespace character I’m using! And I don’t want to have to pay attention to whitespace: that takes time and mental effort that I could have been using to pay attention to the subtle interactions between this class and that other class.

      And so, with some experience under my belt, I’m more and more coming to prefer solution 2 (spaces only), because it’s the only solution that frees me from having to pay careful attention to whitespace, and yet lets me line up parameter declarations in a way that’s easy to read.

      And extrapolating from my own example, where further experience has pushed me towards preferring spaces everywhere, it makes sense to me that more-experienced coders would also, on average, tend to prefer spaces over tabs, which would adequately explain the salary difference.

  97. Is there similar data for those who use vi vs. those who use emacs? 😉

    1. mechler says:

      Gird your loins with regression models.

      Edit: Or maybe GRID your loins with regression models. Either way sounds fun.

    2. Bryan Oakley says:

      There’s no need. Everyone knows emacs users are superior 🙂

      (dons flame-retardant suit)

  98. Megan Robertson says:

    So, does this mean that we need to change how we TEACH coding, and tell the students that they need to use the space bar rather than tabs when indenting?

    1. I think it’s more important to talk about correlation and causation. It’s not the choice of indention that makes a difference in salaries.

      1. Josh Grams says:

        Hear hear. For instance, what if this is just an indication that companies which pay more are more likely to have coding standards that require spaces? Or to have coding standards that talk about indentation at all? Or…something else entirely?

        1. Errol Sayre says:

          Or even, which fields are up-and-coming… the whole equivalent experience vs age question isn’t addressed here.

        2. mechler says:

          This is an interesting line. What if the result is tied more strongly to editor? Larger teams may more typically use larger licensed products (JetBrains, Visual Suite, etc.) which may have defaults (even per language/standard) that push groups of people in one direction or the other. IDEs being grouped into what defaults they use may be a way to model these groups together and they may share some skew toward company types or team-sizes (as someone stated above) etc.

        3. “what if…”? That’s exactly what it is. “companies which pay more are more likely to have coding standards that require spaces” These well paying companies hire good developers. These good developers suggest standards. The companies let natural order happen. The outliers eventually fail.

        4. External Carrier says:

          It could very well be the opposite. In my country, companies that pay more are companies where main activities aren’t related to coding. While on the other end, companies where their bread and butter is coding pay less. I’ve worked for both type. IT companies were really strict on coding standard while non-IT companies didn’t give a crap about it and didn’t even want to hear about it.

    2. benlorantfy says:

      um no, use an editor where the tab button inserts spaces. Pressing the spacebar 4 times to insert a tab would suck.

    3. G. B. Versiani says:


      1. dodekeract says:

        Flexible, like tabs. 😛

    4. Do not confuse spaces with space bar. I’ve never seen an affective coder use the spacebar. Why? Because if you are affective, you don’t put up with inefficient tools, you modify them or make your own. If you can’t conform to space indention, it is a pattern that will also affect other areas.

      1. Jordan says:

        I think you mean `effective`.

    5. Jordan says:

      Actually, in some editors (like Emacs — which I use), when you press “tab”, it inserts 2 or 4 spaces (depending on your configuration).

  99. MakeItFair says:

    That last paragraph starting “Correlation is not causation” is the key. I would have thought that country would make a difference, but evidently that’s not it, given the charts. There might be some other hidden factor at play. It seems strange that just switching to spaces would raise your salary.

  100. grimmriffer says:

    I press tab, but the editor inserts (some) spaces. So, do I use tab(s) or space(s)..? Only one way to find out – convert my salary to dollars and consult the chart! Which was of course the point of the exercise… Uh, or was it…?

    1. This is what every affective developer does. You use spaces. Not understanding what you described is what causes Directors/CEOs and the writer(s) of Silicon Valley (on HBO) to get it wrong.

      1. grimmriffer says:

        Get what wrong? Salaries? I’ll be sure to mention in my next review that although I press tab I’m actually using spaces!

  101. Icho Tolot says:

    Maybe space people earn more because they focus on important parts of their code and not on whitespace. So maybe they deserve it.

    1. Noah Kennedy says:

      Maybe, although I actually believe that legibility is one of the most important aspects of programming. For the record, working with high school students on my old FIRST Robotics team is what really hammered this lesson home. There is nothing worse than a group of junior Java programmers with no understanding of whitespace or legibility in general.

      1. Icho Tolot says:

        I wasn’t advocating for illegible code… mine is perfectly indented, the IDE is taking care of it. Just don’t ask me whether the files contain tabs or spaces… I don’t care and focus on those parts of code writing that the IDE can’t do for me.

        1. Noah Kennedy says:

          Same here. I used to fuss over tabs and whitespace, until I realized that I could ignore it all and press a button to have my IDE do it all for me after I wrote the darn program. I don’t see how this has anything to with tabs or spaces though. Most IDEs that I have used use tabs, so I don’t think that this is the cause of this discrepancy. I certainly do agree with you that it isn’t worth the time to fuss over this too much. I had a friend who would reject all of our GitHub commits if we had even a single whitespace character out of place.

          1. Icho Tolot says:

            The word anal-retentive springs to mind… I suppose he is a well-structured mind and very much cares about perfection, but does he also care about his co-workers’ productivity? Or customer requirements — like deadlines?

            I would reject code that uses logical operator chaining instead of proper if clauses. It’s all the same for the compiler, but a hell of a difference for the reader.

    1. The author explicitly mentions that 🙂

      >Correlation is not causation, and we can never be sure that we’ve controlled for all the confounding factors present in a dataset.

      1. Ionut Botizan says:

        Yeah, a single phrase, with no additional explanations, in an otherwise pretty long article, which roughly translates to:

        > We know all this is irrelevant but we still published this article because we’re trolls and we enjoy an internet fight as much as anyone else! 🙂

        1. Victor Stafusa says:

          They published that because (1) they saw the correlation, which was unexpected; (2) tested for many possible causes linked to other more mundane factors, but none of them explained the phenomena nor warded it off; (3) published the data in the hope that somebody else is able to figure out what the heck is happening here.

        2. dodekeract says:

          They said that correlation doesn’t imply causation. That doesn’t mean that this article is wrong. Maybe there is a good reason why people who use tabs are, on average, paid less and we just haven’t found out why.

          They basically published research about “what doesn’t cause it”, which is just as important as research about “what causes it”.

        3. David Robinson says:

          One thing I’ve found interesting about the response to this post is the number of people who interpreted the title as implying causation. The title explicitly, and intentionally, says nothing about causation. That’s readers projecting upon it.

          Having said that, I don’t think the effect is irrelevant or meaningless, and I don’t think of myself as a troll.

  102. Steve Zagieboylo says:

    Until the last decade, most corporate source control systems did not support setting the tab width. Consequently, looking at diffs in source control used 8 spaces per tab, which is unreadable. Therefore, developers who cared about code reviews insisted that the teams use spaces instead of tabs. (And those who used mixed became pariahs. OMFG.)

    This correlates to higher salaries, because those who insist on code reviews are better developers. So there’s a correlation but not a causal relationship.

  103. sagar patkar says:

    Shouldn’t the conclusion be “Developers, who make more money, use spaces instead of tabs”? The current one makes it seem like developers can start earning more just by using spaces instead of tabs.

    1. Victor Villas says:

      These sentences convey the exact same information. You mind is building the causal relationship here, and it probably doesn’t exist in either form.

      1. sagar patkar says:

        Thank you for pointing that out.

  104. Icho Tolot says:

    I used to be very peculiar about always using tabs… until I started to use IDEs. (Yes, that dates me.) Nowadays I don’t give a f*ck (just like the compilers for real languages) and let the IDE decide. I believe Eclipse and AndroidStudio and Netbeans and Xcode use spaces, no? Anyway, my salary is… very good, so they better do. 🙂

  105. Tab Guy says:

    I use tabs consistently because it makes the amount of indentation configurable.
    That’s more important to me than making money. Maybe that’s the real reason!

  106. Bryan Oakley says:

    My answer to the debate is pretty simple:

    1 – if you are working on my project, you will use four spaces for indentation. End of discussion. I value consistency more than I value your ability to choose.

    2 – if I am working on your project, I will use whatever you tell me to use. I value consistency, and on your project your choice is more important than mine.

    1. mechler says:

      A valiant standard, and one I highly endorse. More importantly though is the discussion about why this data yielded this result. Is something *wrong* with the data or the questions themselves? Is something wrong with the direction companies are going? Can we control for something else within the data to explain what this post is talking about?

      I’m all for having a solid and respectable stance in THE GREAT WAR, but this post is about something bigger and maybe more real/important, imo.

  107. Bryan Oakley says:

    My theory is that there is a non-zero group of people that answered “tabs” who actually use spaces. They answered “tabs” because they either misunderstood the question to be “what key do you press to do indentation?”, or they simply don’t know that pressing tab actually inserts spaces.

    Further this group of people are probably largely inexperienced. Maybe fresh out of school or only have a few years on the job. Their salaries will be lower, thus lowering the average salary for “tabs” users. I would be interested to see if we took, say, 10% of the “tabs” responses from people with less than 5 years experience and switched them to the “spaces” camp, how the results would shake out.

    I base all this on the fact that there are several comments that seem to be from people who are confused about whether they are a “spaces” or “tabs” person since they press the tab key for indentation.

  108. RC_RC says:

    We use spaces because the C++ code we write has to run on a ZOS mainframe too.

  109. Whaaaat? says:

    Spaces for Tabs is cancer. Everyone with half functioning brain knows that. It is generally well known that mediocrity and ineptitude leads to promotions and that’s probably what explains this difference. Also thumbs up for starting another tabs vs spaces war.

  110. a20 says:

    Developers who use spaces are the types who will take the time to figure out how to convert tabs to spaces in whatever IDE they are using.

    They put in more effort than their tab-peers into learning nitty gritty details and therefore accumulate more knowledge than the tab-developers who just use the default settings that come with their IDE.

    Spaces don’t lead to better salaries.

    It’s the mindset behind that habit – that tenacious problem solving mindset – that gives them more experience and confidence for the same number of years worked and that’s what leads to the higher salaries. Space usage is just one of the many qualities they possess that show how deep they are willing to go compared to others who take the easy road.

    1. Whaaaat? says:

      It takes the same amount of time to set your IDE/editor to spaces as it does to set it to tabs. The “easy road” results in most cases in “auto mode” which usually means apply existing standard.

      1. Marti Nito says:

        I tend to use git format. I work with different IDEs on different machines and its a mess to keep codestyle at sync. so i stopped caring about it completely and just use a precommit hook.

    2. Lisandro Mc Gough says:

      I find your premise rather weak. “Developers who use spaces are the types who will take the time to figure out how to convert tabs to spaces in whatever IDE they are using.”
      You might as well state that “developers who use tabs are the types who will take the time to figure out how to convert spaces into tabs (i.e., abstract implementation details away in order to get a representation of indentation levels)” to make the case for tabs if those devs got the better salaries.
      I would rather look into the correlation between hard-core good ol’ days’ technologies and the tab/spaces trends of the day, that might provide a better explanation.

      1. mechler says:

        It makes sense to examine the defaults first, right? A lot of IDEs these days give sensible defaults based on language standards anyway, and finding the people that deviate from those might be a line toward finding real factors that separate one group from another.

  111. Mark Zabel says:

    Quite a funny little survey. Three things …

    1) The author (statistician?) didn’t regress on age of the programmer. That’s different than years programming and might account for generational differences along with the general trend of salaries going up over our lifetimes.

    2) Nobody ever questions whether there actually might be a causal effect! That is, using spaces is a good career move. Was it tested? Or do we “just know” this, you know, like we “knew” the Sun revolves around the Earth for centuries it was obvious?

    3) It’s rare that people don’t form the reverse question either: Does a higher salary mold a person into one who uses spaces rather than tabs? Seems silly here, I know, but it’s easy to be fooled by more esoteric things that often occur in business.

    1. Victor Villas says:

      The author pretty explicitly called out for more people to find other confounding factors and said that correlation doesn’t imply causation.

      1. Mark Zabel says:

        Yes, the author explicitly called for other confounding factors, hence my point #1.

        Yes, the major point of the article is one “correlation does not imply causation.” Point #2 is the opposite. In the paper it’s more or less assumed that using spaces doesn’t cause higher (on average) salaries. But that’s an assumption too! It COULD be causation. (even though our gut reaction is that the two are not causally linked)

        Point #3 is what has been called “cause-fusion”. In this context, “Does using spaces cause higher salary or does higher salary cause using spaces?” (It’s of course possible that neither of those statements are true.) Another example might be, “Do white blood cells cause infection?” If we didn’t know the answer, we could easily be fooled that they do. Why? Because when infection is present, so are white blood cells. It’s only through deeper study that we understand that white blood cells arrive at the scene in order to fight infection. The “cause” and “effect” are not always easy to know.

        1. Victor Villas says:

          I see. I may have misread the intent of your comment, clouding my interpretation.

          1. Mark Zabel says:

            No sweat. The tone of my first comment must have been wrong. I love articles like this! Very fun!

  112. Xsmael The-Best says:

    To be honest i never bothered, i press tab, and my editor will decide….

  113. Asqiir says:

    My guess is that that managers (or whoever employs in the company) feel more like they understand something when space is used than when tab is used. Because they never use tab themselves…

  114. Xsmael The-Best says:

    Am a bit confused, what does matter in this study ? is it press TAB versus pressing SPACEBAR on the keyboard, or is it comparing the spaces characters VS tabulations in your code ?
    Am asking this because it does matter, just pressing the TAB key doesn’t guarantee a tabultion wil be printed it might be spaces as well

    1. Bryan Oakley says:

      It’s about the character that appears in the source code. Most people who use spaces for indentation do so by pressing the tab key.

      1. Bart Van Leeuwen says:

        *SOME* people who use spaces for identation do so by pressing tab for sure, others do so by pressing the space bar. If that makes for most people is not clear from this data in any way, and is merely an asusption some people make based on what they do themselves.

        Unless you have verifiable data confirming that most people who have spaces as identation in their code actually press the tab key, or at least have an argument as to why your statement is likely true, its just that, an unfounded conjecture.

        Here is a possible substantiated guess: most people who grew up learning programming on IDEs and who have space chars for identation in their code do actually press the tab key.

        Virtually everyone who learning programming using more generic text editors for editing their code and who have spaces in their code for identation press the space bar.

        The logic? Most IDEs let you configure the tab key in such a way, while few of the traditionally popular editors did.

        Now… which of the 2 groups is larger? That is likely to depend on age.

      1. I hated that scene so badly! Even as a vim user who insists on spaces, it would annoy me to watch a person hit the spacebar. I would have shown her how to `:set ts=4 sts=4 sw=4 et` and been done with it. Then she can use Tab, Backspace, and Delete and it would work like tab characters. Problem solved, go make love.

  115. Simba Lion says:

    Wow look at those salaries. Developers need to _STOP WORKING FOR
    PEANUTS_. How is anyone supposed to get paid what they’re worth when so
    many are willing to work for half of what they deserve?

    “But they’ll just hire someone else” Who? If the majority of competent
    developers refuse to work for entry level technician salaries, who
    precisely will the managers hire? They certainly can’t do the work
    themselves, or they’d never hire anyone.

    It’s a developers market, stop being afraid to reject crappy offers.

    1. Aelem says:

      In my country, average salary (across all people, not just developers) is $12k. That’s an EU country. Average salary accross developers is $20k per year. Do you still think I could reject “crappy” offers for $40k?

      1. Simba Lion says:

        So do something about it.

        Do you think Americans get paid more because that’s how God wants it? We get paid more because we fought FOR DECADES for higher salaries, and we never stopped fighting.

        Y’all are getting ripped off, I bet your CEOs are raking in just as many millions as CEOs in America, but for some reason the front line workers who do 100% of the actual work are making less?

        Stop working for crappy pay. If you keep taking whatever they give you they will never give you anything worth taking.

        Freelancing and starting your own business are a good answer to this problem. When companies can’t find anyone worth hiring they will have to increase their compensation packages. If all developers were freelance we would all set our own salaries. I bet they’d go up.

        1. Esseuhene says:

          In many other countries (like in France for instance) you are less paid because you have a 100% social security cover (or other advantages like more holidays, less worked hours etc) contrary to US 😉

          1. Lorinc Sonnevend says:

            Exactly! How many paid vacation days do you get, Simba? What about parental leave?

          2. RC_RC says:

            And what about health care in the US?

        2. Aelem says:

          What do you suggest I should do? Stop working? You don’t realize USA is a rich country. Slovakia is a post-socialistic country with ruined economics. The things are getting better here, slowly, we can’t just skip from 20k average to 100k average in a month or so.

        3. Aelem says:

          Sorry, I misread the freelancing part. Yes, starting my own business could be the answer. Maybe if I was in USA.

          Here the economics is such that even if I started my own business, I would probably earn even less or eventually I would fail.

          Also, starting a business requires money (loans?), requires having manager skills (which I don’t have) and requires the competition ability. And if I hired people that I’d pay 100k or even 50k, my company just would not be able to compete on this market.

        4. RC_RC says:

          CEO’s in other countries make less than American CEO’s in general.

        5. Bart Van Leeuwen says:

          Lets merely conclude that 1. compensation covers more then just the money you directly receive each month, and what that ‘more’ means differs wildly from state to state within the USA already, and even more so between different countries, and 2. cost of living varies as wildly between states in the USA, and even more so between countries.

          I could move to a neighboring country, and triple my income, but would have to work twice the hours, and face a triple cost of living. Good deal? not at all as I’d not end up having more money to spend but I’d have less time to enjoy things anyway…

          Please go experience living in other countries for a couple years, I’m
          sorry but your post is full of presumptions and misconceptions. It would really help if you’d start by learning things are different in different places and use that knowledge when in a discussion with people from all over the world about something which is certainly not specific for where you live.

      2. Elizabeth Black says:

        $12k… yikes. That’s less than my rent for a year and I live in a one bedroom apartment. Funny how $$ means such different things depending on where you live.

        1. Aelem says:

          Here in Bratislava I paid $6.7 for the same type of apartment, so as you can see, although we earn 4x less, we only pay 2x less for the apartment.

      3. Mark Zabel says:

        Relative salary is what matters. I live well in Upstate NY on my salary. In Manhattan I’d be a pauper.

    2. Bryan Oakley says:

      $40,000 is a large salary for some parts of the world. Let me guess: you live and work in either silicon valley or in new york or chicago where the cost of living is sky high. Am I correct? There are places where $40k is quite livable, and some places where you can live like a king on $40k/year.

      1. mechler says:

        You’re right about some parts of the world, but I live in a suuuuuper low cost-of-living area and $40,000 is still peanuts.

        I’m with you on this. It’s livable. It’s still a developer’s market and the skill is more valuable than it is being paid.

  116. Jean Vincent says:

    This is amazing, definitely worth a scientific study to try to understand why.

    I do have an idea, not trying to offend people who have a preference for tabs, I suspect that people who use tabs may have a less efficient mindset in the entreprise that overall yields lower salaries.

    It may be because they are too obsessed with low-level, less-important optimizations, lacking a sense of balance with the large set of consequences of a single decision. Not seeing that a good decision from one use case may become a bad decision if it yields a larger set of issues with the set of all use cases.

    So when confronted with other complex decisions, they might be more likely to focus excessively on a narrow set of less-critical advantages, disregarding the larger set of more critical disadvantages of a particular decision.

    When this is repeated over a large number of decisions, this might result in less efficient learning, work and collaboration, these inefficient results would be picked up by professors, colleges and managers, yielding lower salaries.

    A compounding effect might be linked to frustration. The narrow-cases-obsessed individual might become frustrated by his or her inability to convince other people of the validity of their thinking, which is more likely to yield negative, sometimes aggressive, attitudes that are quickly picked up by management yielding lower salaries.

    There may be a link with the large spectrum of autism that seems to be prevalent with software developers, some known to be beneficial, but in some cases, it may become counter-productive.

    That is definitely worth further study.

  117. Dani Pardo says:

    Jezz, he even wrote some source code to analyze the data and produce the graphs, and pushed that to github! That’s what I call being bored and having nothing better to do! LOL!

    1. a20 says:

      Nice try tab-user.

      1. Dani Pardo says:

        SShh!! Don’t tell my boss!

  118. v@disqus says:

    Maybe if we admit that no self-respecting developer would use tabs, this result is less surprising? 😛

  119. Thomas says:

    I changed VS from tabs to spaces, but my boss won’t give me a raise. Is he wrong?

  120. Albin CR says:

    So whats the point of all of this??..

    1. Franklin Fotang M says:

      I’m wondering too.

    2. Whaaaat? says:

      It’s a clickbait.

    3. Bart Van Leeuwen says:

      There being a curious, and to many unexpected correlation between those things?

  121. Gerwin de Groot says:

    And Do People Who Capitalize Every Word In Titles make less money than people who write readable titles? That, at least, would be fair.

    1. Alex N. says:

      That’s called “title case”, a traditional English convention for publication titles practiced in UK and US.
      People that do that probably have a good grasp of English.

      1. Publications in the UK typically put titles are typically in sentences case. Perhaps gp is not accustomed to US English.

    2. KlingOn2K says:

      @gerwindegroot:disqus, they end up getting capital punishment.

  122. Good read.
    Although I have a theory where it comes from.
    I know a lot of programmers that think they’re using tabs, while they’re actually not. Just because they press tab key it makes them think it’s what they’re using.
    And since they finally find it out they realize they were using spaces all the time before. But until they’re less experienced they think it was tabs they were using. Hence there is more inexperienced developers that *think* they’re using tabs, while they’re actually using spaces and that could explain an origin for this inequity

    1. Bob says:

      Conversely, there are some programmers who think they’re using spaces, while they’re actually using tabs.

      For example, when I’m writing in vim, I press the tab key to insert four spaces. When I write in notepad++, I have the option ticked in its settings to behave the same way – replacing tabs by four spaces.

      Or so I thought.

      Turns out, I had that option unticked for the longest time, and I only found out recently when I opened one of my notepad++ scripts in vim, did some changes, and Python started screeching at me about indentation errors.

      Hopefully I’ll get a paying job soon, now that I am correctly using spaces for all my indentation.

    2. Xsmael The-Best says:

      i’m probably part of those who think they use tab Just because they press tab, tell me the difference, how do you actually use tab, and when do you know you are using spaces ?

      1. Most of the times it’s set in your editor.
        For example Emacs always uses spaces unless you set it to do otherwise (f.i Makefile requires tabs). I use Atom and Spacemacs and both of them were using spaces right out of the box.
        A good way to check it, is probably to enable invisible characters in your editor.
        It should look like this:

        1. Xsmael The-Best says:

          alright, so let say my editor, print spaces whenever i press Tab, does that make me part of the developpers who uses spaces ? and potentially make me more likely to be rich :p ?

          1. Yes. That’s the thing (and also a scene in Silicon Valley series that made me mad). People who uses spaces don’t just press space 2/4 times to indent their code. They use tab key, it’s just the editor substitutes that with a set amount of spaces
            So yes. We can all be rich now 😀

          2. Xsmael The-Best says:

            ROFL! i thought that the space users would press it several times to indent, and when i was reading the arguments promoting the use of space and how people are fighting for space i was just wondering how it can be better, since it wastes your time…. anyways thanks for clarification

          3. Bart Van Leeuwen says:

            It may take a little extra time to use the space bar indeed, but if that difference is so big to actually matter, there is something terribly wrong with the typing skills of the person for whom it matters.

          4. It’s not about time. It’s about effort

          5. Bart Van Leeuwen says:

            1. the post I replied to litteraly says: “i was just wondering how it can be better, since it wastes your time”

            So, that clearly argues it wastes time, and *THAT* was what I replied to.

            2. The argument just as much applies to effort. Pressing the space bar a few times is indeed more effort, but if the difference is such to actually matter in any meaningfull way, you might want to review your editing style a bit (200 spaces is not useful indentation 🙂 ) or there is something wrong with your typing skills.

          6. 1. Oh didn’t notice that.
            2. There is a quote I really like “Skill of fast typing for programmers is as important, as a skill of moving pawns fast, to a chess player” 😉

          7. Bart Van Leeuwen says:


            Thats a nice quote and there certainly is a fair bit of truth to it as well, but I know more then a few coders who are indeed limited by their ability to get the code they have in their head into a computer.

            Also, the ability to hit a single key repeatedly with little effort isn’t really an indication of good typing skills, but inability to do so a clear indication of very very bad typing skills.

          8. Bart Van Leeuwen says:

            Some do, some don’t.

          9. Never seen a programmer that would type spaces by hand. Entire programming profession is about automating tedious tasks. If you don’t automate as simple thing as your own indentation then I’d say it says a lot about a programmer like that

          10. Bart Van Leeuwen says:

            That is a bit of a simplistic view on the programming profession. It certainly valid to part of it, but there is much more to the profession then that, for example using computers for things which would simply not be feasible to do by hand, making them do things which do not have any physical world equivalent at all, etc. Automating tedious tasks is also one of the things one can do with programming, a very useful thing, but probably by now not anywhere near the most prominent thing.

            At any rate, it in part depends on what editors you use, what editors you ‘grew up with’, and the capabilities those have, but also on the languages you use.

            I very strongly prefer consistent behavior over saving 3 keypresses. A tab should result in a tab, and a space in a space. That makes the editor work in a consistent way regardless of if I’m editing a Makefile, some python source, some assembler or whatever (note how some of those differentiate between tabs and spaces, where others do not).

          11. Bryan Oakley says:

            It makes you someone who uses spaces. The question isn’t about which key you press to get the indentation, the question is about what character is actually in your source code.

    3. Bryan Oakley says:

      I’ve had the same thought as you. In fact, a few of the responses here in the comments seems to show confusion on the matter. I’ve seen at least one person who said something like “I use tabs. Of course, my editor converts those to spaces”. What they should have said is “I use spaces, though I use the tab key to insert the spaces”.

      I’m willing to bet that if the question were less ambiguous (for example, “my code has literal tabs in it for indentation”), we might have had a slightly different outcome.

  123. Victor Stafusa says:

    For me, I think that most people that uses spaces are already hardened enough to:

    (1) hate the confusion that sloppy/begginers developers do in code base by mixing tabs and spaces in code making the idented tab-size a horrible mess that not works for anyone;

    (2) hate to always be setting the tab size to different settings accordingly to the project (or worse yet, different settings within the same project, or even within parts of the same file);

    (3) hate to see badly idented code when reading e-mails or browsing github. The e-mail client and the browser have no clue about how to correctly set the tab’s size and it is not easy for the user to set this (possibly a different setting for each e-mail and each webpage). Also this is something that should not be a burden to the user.

    (4) hate to get conflicts in git/mercurial/SVN/whatever caused by inconsistences in the use of tabs and spaces (most likely due to mixing them in the identation).

    (5) get disappointed to see that there is some issue in line 234, column 48, but can’t be sure of which column is 48.

    So, more experienced developers which are perfectionist about code, will tend to see that the only way to fight against that mess is to ban tabs to the hell forever, somehow turning them into compile errors.

    1. Aelem says:

      Or ban spaces. The result would be the same.

      1. Tomasz Przybysz says:

        It wouldn’t. You go to view diff of pull request on GitHub and tab indented code is too wide for convenient side-by-side view as GitHub displays tab as 8 spaces.

        1. Aelem says:

          Actually this is the best argument against tabs I have seen so far.

        2. Aelem says:

          Kidding. See
          Every good source code viewer must handle this properly.

          1. Tomasz Przybysz says:

            Good to know, perhaps it’s a new feature or I was just unaware of it.
            Anyway, this way or the other it involves some of effort of finding an appropriate setting option as well as setting it (sometimes each time as here an url has to be amended).
            There are not so good tools in use as well and sometimes it’s not up to a single developer to change a current tool in use. Worth of keeping in mind.

  124. Steve Powell says:

    Interesting; I discovered the other day that YAML files don’t like tabs (different type of file so my editor’s TABS-to-SPACES conversion wasn’t activated, duh!) and of course Python (is it? or at least one language) has indentation being significant, whereas most are ‘free-form’. I know that Assembly languages vary greatly in their acceptance of tabs and their use of spaces. (System/390 Assembler would (still does?) barf on HT or VT characters, but that’s not surprising and largely of historical interest these days.)

    These might be confounding factors it is hard to tease out of the gathered stats.

  125. sh4dow83 says:

    I’m not sure how reliable this is (and any of the salary statistics in the developer survey) considering that you may have mixed part time and full time positions without normalizing those salaries based on the hours actually worked.

    I looked for information about this in the methodology section but since it wasn’t mentioned and that is a common “mistake” (many would probably argue that it doesn’t matter – because somebody who earns 120K for 60h of work per week on average still makes more than someone earning 50K for 20h of work) in salary statistics, I have to assume that you made it as well.

  126. And there they come out of their holes, all those tab-lovers, screaming at us to indent code with a character designed for indentation. You know what? Fuck them! Spaces for the win!

    In fact, spaces all the way! Are you still using line feeds to begin a new line? Boy, all that trouble across different operating systems (to carriage return or not to?) and editors is just not worth it. If you stopped being a Tab-hitting infant, become a real man now and stop using Enter as well! I just fill my lines with spaces until the editor wraps it around. That’s what true 10x ninjas do.

    1. Bryan Oakley says:

      Son, the 1950’s ended a long time ago. 🙂

  127. Frank Sheeran says:

    I’d like to see the same comparison between emacs and vi, and between various Unix shells.

  128. John says:

    What if I use tabs but my text editor convert them to spaces ?

    What if I use spaces, but use tabs in Makefile ?

    1. Bryan Oakley says:

      Then you are in the “spaces” group. It’s not about the key you press, or about languages that require literal tabs. It’s about what character is in your source code to represent indentation.

  129. Alex says:

    one of the first things when you start as developer is question spaces or tabs
    whoever I asked years ago said spaces, as Tabs has different settings in different computers so that was easy one, it respects the nature of programming which is make it work everywhere possible

    1. Aelem says:

      That’s BS. The possibility of setting tab width is actually an argument for Tabs, not against. Also, I say tabs, so I may be your first. 🙂

      1. Toon Van Acker says:

        This only *really* works if you use tabs for indentation, but spaces for alignment past indentation, tho. Otherwise you can get awful results when you vary the tab size.

        1. Aelem says:

          Don’t use alignment. You don’t need to.

      2. Tomasz Przybysz says:

        I know that this argument is used as a tab advantage but it’s an invalid argument. Please see my comment over here to understand why (shortly, there are many places in which one has no influence on how tabs are displayed).

      3. Alex says:

        I think you should listen to Tomasz and don’t be ignorant and proud for being wrong 🙂
        not necessarily totally wrong, but wrong about tabs being better option for viewing code

  130. Pat McKillen says:

    You don’t need a survey of this size and complexity to come to the conclusion that space is better than tab. Imagine the sort of childhood people of my generation would have had it the tab brigade had won. I would have played “Tab Invaders”, Captain Kirk would be talking about “Tab, the final frontier” and David Bowie would have had “Tab Oddity” as one of his many many great songs.

    On the flips side, I would not be the owner of a Tabby Cat but rather a Spacey Cat – which would be kinda nice.

    1. Bart Van Leeuwen says:

      The survey does not say that, rather it says there is a curious correlation and points out, more then a few times, how that does *not* imply causation.

  131. Cedric says:

    Could it be that guidelines tends to favor spaces, and that bigger companies tends to have guidelines (and enforce them), and also that bigger companies pay more ?

  132. Wasim Hyder says:

    Now I know why he has troubles in making his company stable.
    IYKWIM 😛

    1. Joe Delekto says:

      Too funny, I actually caught that subtle exchange in a recent episode where he didn’t hire one of Gavin’s suggested engineers from Hooli because he used “spaces instead of tabs”.

    2. Yung-Chun Lu says:

      Can not agree more T^T

    3. Xsmael The-Best says:

      i dont get anything…

      1. Wasim Hyder says:

        Xsmael it a reference from HBO TV series named “Silicon Valley” where person in the picture “Richard Handricks” is a developer who is trying to run a compression company with his revolutionary compression algorithm and is obsessed with the use of tabs over spaces.
        It is a great series. I think you should watch it.

        1. Xsmael The-Best says:

          oh okay, now i kow why i didnt understand, i’ll give it a try when i get free time, thanks!

  133. Boris The Blade says:

    I think the cause is somewhat reversed. I strongly believe that people who use – and fight for – spaces are young and proud, quick to respond when you ask their salaries. Speaking generally of course. They also likely to use a modern framework like PHPStorm, or a freshly invented editor like Atom, they use Git for version control, share their work on github or other communities, also format their code with autoformatters – these things typically cause spaces. The key concept here, I believe, is that they’re TEAM PLAYERS, most with university degrees. Yes they earn more.

    Whoever uses tabs clearly doesn’t give a sheet who reads their code. One-man companies, freelancers, not speaking about their salaries or not having a consistent value per month. Tabs have added value when you code but are somewhat annoying when you git often, or when others see your code in a viewer with 8 as default tab size.

    These are factors to consider.

    I use tabs and I’d typically not tell my salary. I don’t use it for reasoning.

    1. Ashley Sheridan says:

      Erm, whut? PHPStorm isn’t a framework, it’s an IDE. I’m not sure I can take you seriously now!

      Given that you also don’t know that tab size is arbitrary, you don’t seem to quite understand. The argument you’re making against tabs is actually the opposite of the situation and the exact argument that shows why space indentation is a problem…

      1. Boris The Blade says:


    2. Aelem says:

      So many BS.
      1. “Young and proud” don’t earn more. They earn less. Because they’re young.
      2. Freshly invented editor Atom tries to detect which mode is used in the file we edit and sticks to it. If it can’t, it defaults to spaces, but can be switched to tabs in settings. Also modern editors respect .editorconfig file.
      3. Neither git nor github don’t have any problems processing tab-indented sources.
      4. “Whoever uses tabs doesn’t give a shit who reads their code”. BS. It’s the opposite. With tabs, I’m giving you the chance to setup your editor / source view to your preference. With spaces, I don’t.
      5. I use tabs and I have no problem telling my salary. And I earn more than most of other developers in my country.

      1. Boris The Blade says:

        1. Read again. Team players with uni degrees do earn more.
        2. Yes, practically all editors can do this trick. Missed the point.
        3. Yes they do. Not git itself, of course, but people with different indenting habits, working together. Some clients stick to the idea that whitespace changes are changes.
        4. Interesting idea but no. If you care about others you’ll practically always convert your tabs to spaces, to make it viewer-agnostic – in other words, to make your code look exactly one way and not another. Simply put, I like tabs but teams usually don’t.
        5. Maybe. So what.

        1. Aelem says:

          1. BS. Everybody is a team player. Uni degrees does say literally nothing about whether the individial is young or uses spaces. Young people earn less, because they are not that skilled yet professionally.
          3. The problems is different indenting habits, not using the tabs. If the tabs are used and enforced in the whole project, there is no problem at all. If the spaces are used but not enforced, you can get into the problem as well. Different indenting habits does not say anything about whether tabs are better or spaces are better.
          4. I don’t think you can be serious at this point. How can setting something to be viewer-agnostic be helpful to the viewer. It’s viewer-agnostic, you said it your self. Not viewer-helping. I, as viewer, don’t want to see your ugly code indented with 2 spaces. I want to see it indented 4 spaces.
          5. Nothing. Exactly like your last paragraph in original post.

          1. Boris The Blade says:

            1. No.
            3. Yes, that’s what the whole discussion is about.
            4. If you want to see a code differently, format it. But space believers have a valid point when they say “I wrote it like this so it should look like this”. When I post something for code review I convert my tabs to spaces. They ask me to and I respect them. I mean I see your point but it’s almost unique, I encountered two or three people thinking about tabs like that. Most of them use the de-facto standard (4) and convert them back and forth as needed.

          2. Aelem says:

            1. Maybe you’re too young. Go ask your colleges.
            3. No. The discussion is about whether tabs or spaces are better. Tabs are better. Mixed indentation is bad in all cases.
            4. Format it. You’re kidding. So what you’re suggesting is not to be a team player. Actually, that’s why tabs are better than spaces. With tabs, I don’t need to reformat the code and still get the way of seeing the code I like.

            “They ask me to and I respect them.” – of course. When they use spaces, I use spaces (on that project). That is crucial. But it doesn’t say anything about whether spaces are better. They are not.

          3. Boris The Blade says:

            This discussion is NOT about which one is better. This is about a correlation that’s hard to explain. And kids, how many times do I have to tell you I’m using tabs? Please don’t start to convince me about them. I’m using them since the 1900s. I know the pros and cons.

          4. Aelem says:

            You made some statements, such as “Whoever uses tabs clearly doesn’t give a sheet who reads their code”, which are plain wrong and that’s what my replies were about. The fact you’re using the tabs doesn’t make them right generally. Maybe you should have written “I use tabs and don’t give a shit” instead.

          5. Aelem says:

            *doesn’t make the statements right

          6. Boris The Blade says:

            Whoever wants to understand what I’m saying already does.
            Whoever tries to misinterpret can always find a way to.
            This conversation serves no purpose. You never learn. Keep posting “this is bs” on everything and be happy.

          7. Aelem says:

            Well, whatever. You’re wrong that I tried to misinterpret. I didn’t. I don’t think I did. I can finally agree with you on that this conversation serves no purpose, because you never learn either.

          8. Tomasz Przybysz says:

            >You made some statements, such as “Whoever uses tabs clearly doesn’t give a sheet who reads their code”
            Because that’s true. I replied somewhere above to this but let me repeat myself. Try to set how tabs are displayed in tools / web pages, which simply don’t have possibility to set this. You’ll end up being ‘forced’ to view tabs as 8 spaces and this usually has a really bad impact on code readability as it gets too wide to fit on the screen (text column).

            I don’t really care about what character is used as long as it’s not mixed in a single codebase. However if codebase is meant to be shared among a team or even public, use of spaces guarantees there will be no issues which are brought by tabs.

          9. Aelem says:

            No, it’s not. If you use wrong tools, it’s not the problem of tabs. It’s the problem of IDE. Even github can display different size of tabs with the right setting.

            There are no issues brought by tabs. Only issues brought by mixing the styles.

          10. Tomasz Przybysz says:

            I’m just pointing out that with spaces there in no problem at all, no matter what tool is in use. This is a sufficient argument IMO, as use of spaces is always effortless.
            So all goes down to whether someone prefers to pay some additional effort for more flexibility (adjusting how the tab is displayed). In a team the choice is more often not to go with this path. What is a choice of a single dev coding “to his drawer” is a personal preference and no one cares, I guess.

            As I don’t mind much use of either tab or space for indentation, I totally agree that mixing is a great no-go.

          11. Bart Van Leeuwen says:

            You do not always have the choice of tools. Also, who are you to tell anyone what the ‘right’ tools are? The team player who advocates that tabs give you freedom to change the indentation at the expense of choice of tools? That sounds like penny wise but pound foolish.

          12. Bart Van Leeuwen says:

            You so far make a purely theoretical argument about why tabs would be better which simply ignores a number of things from reality.

            What I’ve noticed over the decades is that people who strongly advocate tabs often have a strongly academic approach to things (which certainly has its value), but just as often get too distracted by what could be better in a theoretical idealized world simply does not work that way in practice.

            So all theoretical arguments aside, spaces work regardless of the tools, whereas tabs are problematic with a number of tools. Simple conclusion, in todays non ideal world, spaces are better in spite of the theoretical advantage of tabs.

          13. John B says:

            I’m going to go out on a limb here and say Aelem is a better developer when it really comes down to it. More value add. I’ve seen this time and time again. Generally people that are ardent about this debate either way are wasteful fools, but I’ve consistently noticed the spaces people arguing for their side using tactics Nassim Taleb would describe as “Intellectual Yet Idiot”. They’re elitist and don’t truly think from the perspectives of other people, just some mythical “team” ideology they’ve made up in their minds.

          14. Bart Van Leeuwen says:

            “Everybody is a team player.”

            Uh no, but being a team player also has zero to do with having a university degree.

            “The problems is different indenting habits, not using the tabs.”

            Got a point there. Want to work on a project as a team? ONE indenting style, and you stick to it, no exceptions.

            “I don’t think you can be serious at this point.”

            I’m sure you are simply not getting it due to lack of experience with a very wide range of editing and viewing tools. No, not all of them let you set tab size, and many of them will default to 8 and create totally crappy output, WITHOUT the user being able to change that. Also there are many situations where the user simply has absolutely zero choice in what tool to use. Spaces work the same everywhere, and ensure consistent formatting and hence viewing in every available tool. It indeed removes a tiny tiny fraction of freedom for the viewer to set tab size to 22 instead of 4 or whatever you want, but that is really a small price to pay for everyone being able to at least use it.

            As team player you should be putting what works for everyone in the team over whatever personal preferences you might have, the later are for your personal pet projects, unles you happen to be the team lead and in the position to make your own preferences the standard.

  134. agtrier says:

    You may want to look up “spurious correlation”…

  135. tonicboy says:

    Fascinating post but obviously, there is _some_ confounding factor which just isn’t apparent yet. I mean, it’s literally impossible for spaces to be a _cause_ of higher salary. If that were the case, then developers should be able to switch from tabs to spaces and see their salary increase (good luck with that!).

  136. Meet Taraviya says:

    This is an elaborate lie cooked up by space users, that’s what they are good at!

  137. Jacob Raihle says:

    Explaining the result is easy: If someone is going to force me to use spaces, they better be paying well.

  138. Alexander De Sousa says:

    I would imagine it’s the IDE the developer uses, i.e. cheap companies paying cheap salaries will only supply cheap IDE’s which may just happen to have tabs as default software.

    By contrast high budgets, high salaries, good IDE’s.

    P.S. I haven’t checked what the defaults in each IDE are.

    1. Ashley Sheridan says:

      What would you class as a cheap/good IDE? I’ve yet to see an IDE that couldn’t use both, and allow the dev to switch between the two. Of course, when it’s all in your imagination, then I suppose anything is possible…

      1. Alexander De Sousa says:

        Cheap = free, Good = paid. I know you’ll pick me apart on my original wording there as you can get good free IDE’s but that’s not what I’m talking about.

        I’m also not talking about an IDE locking you into a specific preference, I’m looking at what comes as default since we developers are too lazy to change that default.

        The 2 big players here are Eclipse (default is tabs) and IntelliJ IDEA (default is spaces).

        In that situation it becomes more a reflection of the company, i.e. a company valuing the tools a developer uses enough to pay for them may also be competitive with salaries. By contrast a company forcing developers to find free IDE’s as a means of cost saving, may also be a little tighter on the salaries.

        1. Ashley Sheridan says:

          I’d say Netbeans, Visual Studio, and PHPStorm are also pretty big players here too. But I agree, developers are inherently lazy (that’s why we spend our time getting computers to do things for us) so we tend to go with whatever defaults the IDE suggests.

  139. Indomitable Jision says:

    How does that defines what is more optimal spaces or tabs??

    1. Ashley Sheridan says:

      The best argument I’ve seen for each: spaces allow exact indentation for when code wraps onto more than one line (yes, it’s not ideal, but it *does* happen). The arguments for tabs are: allow you to indent to exact points consistently, allow you to set the visible tab width without changing the actual code by a single byte, use less space on the hard drive/memory 4 bytes for 4 spaces Vs 1 byte for a single tab (a poor argument that last one, but I’ve seen it used)

  140. Attila Fulop says:

    We’re using tabs, because it’s God’s word. Except for Spacial Fridays, then we can use spaces.

    1. Victor Stafusa says:

      Tabs are a creation of the devil to seed discord between the men.

      1. Ashley Sheridan says:

        Tabs came first as the best way to indent. Spaces came after because people didn’t know how to use tabs and line things up with spaces. We laughed at them when they did it on typewriters, we laughed louder when they did it on word processed documents, now we cry when they do it in their IDE. 😉

        1. Bryan Oakley says:

          The horse and carriage is the best way to travel, since it came first. Cars are for people who don’t know how to handle horses.


          1. Ashley Sheridan says:

            Oh, I’m sorry, would you like me to dumb it down to idiot level?

          2. Bryan Oakley says:

            No thanks.

          3. Ashley Sheridan says:

            You’re great at these strawman arguments aren’t you? See that bit where I said that the spaces indentation is because people were idiots and didn’t know what a tab was? That doesn’t make spaces better; in-fact if you’ve ever seen someone trying to indent something with a typewriter using spaces, it’s obvious that spaces are not superior in the same way that a car is superior to a horse and cart. Comparing two different things makes no sense and derails the discussion.

          4. Bryan Oakley says:

            All I did was point out the fallacy of your “tabs came first” argument. Just because something comes first doesn’t mean it is the necessarily the best solution in the modern world. Many things come first, we learn from them, and we adapt.

      2. Attila Fulop says:

        Do you have Tabular Fridays then?

  141. natalinobusa says:

    great. That settles spaces vs tabs now let’s clear line terminations styles. 🤘

  142. Bob Gezelter says:

    Considering that the use of tabs is highly editor dependent as well as platform dependent, I seriously doubt that it is tabs vs. spaces that is driving the salary numbers. IMHO, it is far more likely that a premium is being paid for environments where tabs are not generally used. Plotting individual technologies individually would be far more clarifying (e.g., z/OS assembler, C on Windows, Python on Linux).

    1. Ashley Sheridan says:

      I don’t understand how a tab can become editor dependent? A tab is just a byte in the code. You set your editor to display a tab as a certain width of characters. That’s it, simple. There’s no dependency on anything. If you move to another IDE, just change your default settings there to your liking (as we all do, who likes to be stuck with stock layout and colours?!) and then you’re all set.

  143. Ruchit Surati says:

    Just because there is a co-relation, doesn’t mean it’s a driving factor. Misleading hypothesis.

  144. Clearly users of spaces are more prone to lying about their income than are users of tabs 😉

  145. Juan Story says:

    Another explanation would be that developers who use spaces lie about their salary

  146. Cade Perkins says:

    There must be a correlation between size and number of thumbs each coder has vs the size and number of left little fingers.

  147. Cade Perkins says:

    The majority of tab users must be from regions where the comma and period are reversed in numerical values. “Do you indent code with tabs? Yes” “What is your annual salary? 130.000” $130 would certainly bring down the average.

    1. David Robinson says:

      A. The above post used median, not average
      B. The effect was entirely clear only within the US, as shown in the second graph above

      1. Cade Perkins says:

        I was just adding some humor, so median or average wouldn’t matter. But I’m not sure how you’re reading the second graph. It looks apparent to me that the effect is there in all countries shown, not just the US.

      2. Ashley Sheridan says:

        Median *is* an average. Don’t fall into the trap of assuming average == mean 😉

    2. Tim Hitchins says:

      In continental europe they use the apostrophe (‘) not the . I believe.

      1. Tom Walton says:

        Not for thousand separators, most use ‘.’ As in 1.000

      2. Cade Perkins says:

        Just a little humor. I didn’t see the survey, but I assume it didn’t accept such erroneous values. It is just humorous how many serious responses there are to this–it needs a lighter side. Otherwise, I’m familiar with German and some other European formats and they definitely use a period for thousands separation (and many use a comma for the decimal delimiter).

      3. Attila Fulop says:

        OK, here’s the real twist: in Hungary and in Romania we use spaces for thousands separator. Maybe we could start using dots for indenting, just need a decent transpiler 😀

      4. Steven Roose says:

        We don’t. I guess the most common is a space as the 000 separator and a dot or a comma for the decimal, depending on country.

  148. Cade Perkins says:

    s/t/ /g

  149. Stelios Serghiou says:

    Strictly speaking, causal inference is impossible in cross-sectional data because they violate the principle of temporality, i.e. we need to observe exposure (in this case tabs/spaces) and baseline values, before the outcome of interest (in this case salary). Thus, we cannot use causal language in describing this estimate. Nevertheless, even if we were willing to assume that our data would have remained unchanged had this been a prospective study (which is not unreasonable for variables such as country of origin), after having had a look at the raw data, it would take a while to turn this dataset into a readily analyzable object. The main issue would be the huge amount of missing outcome data, some of which is probably missing at random, some of which is most probably not. Certain variables also contain multiple responses for each person, which would have to be dummy-coded, but that’s not too big of an issue. After dealing with these, the easiest approach would be to use principal components analysis to identify components of interest, use them to calculate propensity scores (i.e. the probability of an individual using spaces/tabs) and then run ordinary least squares of outcome on exposure and propensity score. There are more interesting approaches as well (e.g. double machine learning)..

  150. Cade Perkins says:

    New resume skill: Code with spaces only.

    1. Reini Urban says:

      Nope. Use the right tool.
      But sometimes MSVC is the right or better tool, and still people get away with tabs, even with 4 char tabs, which is very common amongst MSVC coders.

  151. Saurabh Gupta says:

    Error Bars please?

  152. Alex Lev says:

    What about ANOVA?

  153. Louis Sayers says:

    People! Just map your tabs to spaces in your editor and let’s have this debate over with… 😀

    1. Yeah, then go to your boss and tell him, that you now need to get more money 😀

    2. Ashley Sheridan says:

      Yeah, so Joe maps his tabs to spaces, and sets his IDE tab width to 4 spaces. Bob comes along and doesn’t like 4 spaces, it takes up too much room on his screen, he prefers 2 spaces. He changes this in his IDE. Bam, he’s just changed every line of code, and Joe isn’t happy. If only they knew how to use tabs properly, this would never have happened!

      1. David Robinson says:

        True, but then they’d lose 8.6% of their salary.

        1. Ashley Sheridan says:

          correlation ≠ causation 😉

      2. Bryan Oakley says:

        It can go the other way. Joe uses two-space tabs. His code looks all nice and pretty and readable. There are a few odd sections that need to be indented 12 characters over so he uses six tabs. Bob comes along and has an eight-space tab. Suddenly all that code that needed to be indented 12 characters is now indented 48characters, and looks like crap because half of the code is beyond the right margin.

        1. Ashley Sheridan says:

          That’s not how tabs work. It’s cute that you’re trying to get involved, but you don’t know what a tab is, so maybe leave your betters to discuss stuff, eh?

          1. Bryan Oakley says:

            “it’s cute” is such a juvenile response.

          2. Ashley Sheridan says:

            Discourse is horrible for so many things, that’s not the fault of tabs, and trying to make it so is daft at best.

          3. Bryan Oakley says:

            I’m not saying it’s the fault of tabs. What I’m pointing out is that there are many tools used by real world programmers that don’t play well with tabs. Discourse is but one of many tools I’ve used over several decades that doesn’t handle tabs properly.

            For that reason, tabs are IMHO a less practical choice unless you work in a relatively closed ecosystem.

        2. Ashley Sheridan says:

          Another strawman, good for you. Stop confusing alignment with indentation.

  154. Nokola says:

    Most developers who use tabs didn’t have time to answer the SO survey because they were busy counting the ton of extra money they were showered with 🙂

    1. Ruby Linquista says:

      This is sort of the answer I wanted to find on here. Also, StackOverflow itself skews results because it has a certain demographic.

  155. weffyman says:

    what if some editors are adding spaces when user tabs?

    1. Then you are using spaces.

    2. Ashley Sheridan says:

      You can change this setting in your editor 😉

  156. Lawrence Mok says:

    may be it’s 8.6% increase in file size…….

    L E T S U S E M O R E S P A C E

  157. BillBasham says:

    Obviously we are paid by the character…

    1. AndrewEddie says:

      The income per character is higher for tabber’s 🙂

      1. Ashley Sheridan says:

        That makes no sense…

  158. KlingOn2K says:

    Now I know EXACTLY why I am underpaid !
    I have been using those doggone tabs for 10 years !!
    Bye, bye tabs. Spaces, here I come !!!

  159. Turi says:

    Simple solution: Use tab and automatically replace tabs with four spaces. Best of both worlds.

  160. Quaid Ferguson says:

    Using tabs to indent and align code is like trying to use a hammer to clean your windshield.
    Lets say you have a function with a lot of parameters.
    public void foo(int bar,
                            string foobar,
    Depending on how wide your tabs are and how long your function signature is, chances are this cannot be aligned. Simply not acceptable.

    1. Brian Jacobs says:

      :set ts=2

    2. abatishchev says:

      You’ve obviously misunderstood the whole concept of using tabs for indentation

      1. Quaid Ferguson says:

        Really? Then why don’t you enlighten me.

        1. If you ask a tab-using heathen, you’ll find their response to be “tabs adjust to whatever size you need.”

          1. Bart Van Leeuwen says:

            And that works as long as your tools properly support that, and as long as the language you use doesn’t differentiate between tabs and spaces.

            Its usually more a case of militant tab advocates suggesting a ‘freedom’ of viewing argument while actually limiting your ‘freedom’ to use the tools of your choice, and also tend to not want to know about how in many professional environments you do not get to pick your own tools.

    3. Xandor Schiefer says:

      There’s a difference between indentation and alignment. Tabs clearly suck at the latter. They are, however, better than spaces at indentation. Indentation is what they are the character for, with no other purpose.

      The Best Way™, is to use tabs to indent and spaces to align. Let each character do what it’s good at.

      But let me also say that consistency in style is far more important than which style is actually used.

      1. Bart Van Leeuwen says:

        (horizontal) Tabs are not intended for indentation, they are intended to move the cursor to the next preset tabstop on a line. It just so happens quite a few people believe this is a convenient way to indent code.

    4. Ashley Sheridan says:

      Ideally your functions should not have that many arguments that this becomes necessary. It’s true this is a failing of tabs, but using spaces to indent now means that you’re forcing every single dev working on that code to use the exact same number of spaces everywhere. So it doesn’t matter if Joe likes 4-space indentation and Bob prefers 2 on his screen, everyone has to have the same. Using tabs, that isn’t a problem, everyone gets to set the visual width of tabs as they please on their own IDE.

      1. Bryan Oakley says:

        > “you’re forcing every single dev working on that code to use the exact same number of spaces everywhere.”

        Why is that a problem? If the team shares the same coding conventions, the code will be easier to read and maintain by the team as a whole.

        > “Using tabs, that isn’t a problem, everyone gets to set the visual width of tabs as they please on their own IDE.”

        It also means that code that looks properly aligned by someone who uses two-space tabs may look like crap for the guy who uses 8-space tabs (or visa versa)

        1. Ashley Sheridan says:

          It’s a problem because not everyone using your code is necessarily a team member.

          Also, if your code alignment looks shit when adjusting tab widths in your IDE, then you’re not indenting, you’re aligning. Big difference, but the sort of mistake I’d expect from someone who isn’t a team player

          1. Bryan Oakley says:

            You can preach “indent with tabs, align with spaces” all you want. In the real world, people who use tabs for indenting will also sometimes use tabs for alignment. That’s just the way it is. I’ve seen it with my own eyes by really brilliant programmers. You can live in an ivory tower and say it shouldn’t be so, and look down upon those less enlightened than you, but that doesn’t change the fact that code that uses tabs will indeed sometimes looks bad if the one doing the reading doesn’t have the same tab settings as the one doing the writing.

            That being said, that’s not the end of the world. If 99% of the code looks fine, I’m cool with that. If you want to use tabs I’m certainly not going to stop you. At the end of the day you’re the one that owns the code you write. If you think using tabs makes it better, that’s all that matters as long as the rest of your team agrees.

          2. Robin Munn says:

            In the real world, people who use tabs for indenting will also sometimes use tabs for alignment. That’s just the way it is. I’ve seen it with my own eyes by really brilliant programmers. (Emphasis mine)

            THIS, right there, is the problem in a nutshell. “In theory, theory and practice are the same. In practice, they’re different.”

            In theory, tabs are better than spaces because everyone can set them to their preferred level of indentation, and everyone knows how to use them correctly (tabs ONLY for indentation, then spaces for any alignment you want to do after the indentation level).

            In practice, tabs are worse than spaces because everyone can set them to their preferred level of indentation, and not everyone who knows how to use them correctly will actually use them correctly, alas.

            And so, the more code I read that has used tabs incorrectly, the more I’m inclined to dictate spaces-only in any project I lead. Because the inflexibility of spaces is the only way to ensure that two coders with different tab-width preferences won’t mess things up for each other.

    5. That’s a horrible practice! You rename foo and all your nice formatting goes out the window. If you absolutely have to align, do this:

      public void foo(
      int bar,
      string foobar,

      1. Quaid Ferguson says:

        If you are using decent tools, the rename refactoring will automatically realign your parameters.

        1. I’ve seen so much formerly aligned parameters that I just assumed IDEs didn’t do that very well. I just checked with IntelliJ, though, and it indeed does. So you are right, decent tools (and proper configuration) for the win! I still don’t like this kind of formatting (because horizontally speaking, every parameter list is somewhere else) but that’s more a matter of taste than actual problems.

          Unfortunately for tab-lovers like myself, IntelliJ supports your original argument. The aligned parameters should use the same number of tabs as the line above (for the indent) and fill the rest up with spaces (for alignment) but it doesn’t. Instead it uses as many tabs as possible so things get unaligned for a different tab length.

  161. the great woomy says:

    I don’t think you took into account the fact that TRUE DEVELOPERS just use semicolons and have all their code on one line.

    1. Robin Munn says:

      And they eschew inserting those semicolons by such gauche methods as actually touching a key, preferring to use butterflies instead.

    2. Mario Rivera says:

      True developers don’t need multiple statements, it’s a single perl line.

  162. Jasper Rijkeboer says:

    Who knew that professional developers who have learned to “play well with others” in multidisciplinary environments would actually be paid more than silo’ed purists. Huh…

    1. Ashley Sheridan says:

      If by playing well you mean forcing a specific width of indentation on their code to all devs who work with it, yeah, sure, because that’s what you’re doing with spaces 😉

      1. Bryan Oakley says:

        I’ve yet to see a good argument for why it’s a good thing for different developers on a team to adhere to different coding standards.

        1. Ashley Sheridan says:

          I’ve yet to see a good argument about how indentation is the same thing as coding standards

        2. Ashley Sheridan says:

          Now you’re making strawman arguments. I’m not going to reply in defence of an argument I didn’t make…

      2. Bart Van Leeuwen says:

        Maybe the correlation isn’t very difficult to explain… those using spaces can easily adapt to whatever environment and get things done, whereas those using tabs have more difficulty fitting in with things which aren’t 100% their own choice and waste their time on arguments 🙂

        1. Ashley Sheridan says:

          Actually, I think you’ll find it’s the opposite. Indentation is spaces by default on most editors. Blows your whole argument out the water, eh?

  163. Laurent says:

    Reading these comments, one thing space users seem to have in common is a strange feeling of superiority (a recurring argument is that tab users are messy and don’t know what they’re doing, while space users care about the quality of their code), so that could be a clue. Higher self-confidence, regardless of merit, usually translates to higher salaries.

    1. Quaid Ferguson says:

      Yes, when you have good reason to believe you are correct, it inspires confidence.

      1. catalysto says:

        Case in point.

        1. Quaid Ferguson says:

          Case in point only if the confidence is regardless of merit, which is exactly what I was arguing against.

    2. elequ says:

      But don’t tab users just have the same level of confidence for different reasons? Neither is default, you need an equal amount of confidence to use either.

      The neat v messy code argument seems more legit than the confidence one.

    3. Bart Van Leeuwen says:

      I see individuals on both sides in that discussion having a similar strange feeling of superiority.

  164. Bruno Brant says:

    Another cool “statistic:” most of the developers who work with me DON’T have a SO account. Based on my sample I can safely guess that most developers on my company don’t either. (at least at my region)

    That wouldn’t matter – until you I tell you that my region comprises 12.000 people. Not all of them are developers, but it’s a software consultancy, so most are.

    Conclusion: this is the most stupid post I’ve seen. The sample is very, very, very small to the point of having zero meaning. I began reading it as a joke but ended up realizing that the author was “kinda” making a point.

    And the only point is the usual one when reading the interpretation of any statistic data: beware.

    1. Most developers in the world don’t have an SO account. That’s irrelevant. An argument that developers who answered the survey are not representative would be relevant.

      1. Nutarama says:

        Is there any reason to believe that the SO userbase is representative? I’d imagine that the SO userbase skews towards self-taught programmers, more extroverted programmers, and more English-fluent programmers. Most people interact with it when they have problems that they can’t answer (professionally taught developers should have a reference text for answers) and only a few of those visitors are going to be willing to take the time to join the site to interact with others and eventually answer the survey.

        1. It’s certainly representative of something. The kinds of points you make are exactly what should be discussed if you’re going to argue that there are factors related to the topic at hand that are ill-represented in the sample as compared to the full population.

        2. Adam H says:

          Unless any of those differences in representation is actually a confounding factor for the relationship between tabs/spaces vs salary then none of that explains the reported differences.

        3. Cade Perkins says:

          “Professionally taught developers should have a reference text?” All due respect, but what wonderful reference text do you have that is 1) primarily available only to professionally-taught developers, 2) includes an index of all possible bugs, hardware problems, system profiling measurements, etc, 3) libraries of additional code that does just what you need right now, 4) consider all possible new technologies and languages, etc. Even if you’re correct that SO is not representative of all spacing and tabbing coders, I can’t imagine that your reasons are any more justifiable than the conclusions in the article.

        4. “Professionally taught developers should have a reference text?” – what a strange comment!

      2. elequ says:

        Yup, this can also be generalised to every survey of anything ever. This is the way they work: small *sample* of *people who answer*.

        Also are there really many developers out there who don’t refer SO? That’s like saying they don’t use google. As code is not science (ie it can not be independently/empirically looked up), you **have** to look up references. This is a case where SO is probably a relatively solid survey.

        1. Bart Van Leeuwen says:

          You certainly can create code independently and without reference to SO, in fact if that weren’t possible, none of the examples and answers on SO could exist at all. They were invented/discovered by people, often more then once.

  165. Spencer Shanson says:

    Now that the Tab v Space argument has been sorted out, what’s it going to take to make everyone realize that 4 space indenting is better than 2?

    1. Christian Gollhardt says:

      Haha, How about 3? 😛

      1. Spencer Shanson says:

        Four shall be the number thou shalt count, and the number of the counting shall be four. Five shalt thou not count, neither count thou three, excepting that thou then proceed to four.

    2. Around the same time people stop writing the forty-line-long `if` blocks that make two-space indentation a truly serious barrier to reading the code rather than a mere annoyance. (That would be “never.”)

    3. Jon Ericson says:

      Companies ought to start paying by the keystroke. Then we’ll see comfortable 8-space indentation like God intended.

    4. Ashley Sheridan says:

      See, you’ve hit the nail on the head, the width of indent is the exact problem that spaces creates and can’t solve. You prefer 4 spaces, Bob prefers 2, Joe prefers 8. Thing is, when you’re using spaces, you are forced to use only one width, whereas with tabs, anyone can set the visual width on their IDE and it doesn’t affect the code for anyone else!

      1. Spencer Shanson says:

        If only it worked like that. Too often I’ve seen files with mixed tabs and spaces because developers have different preferences. So then you ask your IDE to convert all the spaces to tab (or vice versa) and now you inject all these changes into the file diff.

        1. Ashley Sheridan says:

          That’s not a problem with the indentation method, it’s a problem with that team not having coding standards…

    5. Bryan Oakley says:

      I’ve worked on teams that used 2, 4, and 8. Of those, I think I hated 8 the most. I will agree that 4 seems to be the sweet spot — enough to be visually distinctive but not so much that the code extends beyond the right margin.

  166. Laszlo Marai says:

    What if it’s related to nerdiness (and through that social skills), unwillingness to compromise and thus being worse at (or in a worse position) negotiating the salary?

    Or, I don’t remember what the original survey said, but if there are more space guys then tab guys, then the space guys might just oppress the tab guys (space tech leads offering lower salary, space leads/peers giving worse reviews, etc.). Which they may not even notice, just somehow observe the tab guys as worse or more problematic developers in general. (After all, this has been a very good reason to start a flame war any time for quite a while 🙂 )

  167. Tez K says:

    This makes sense. People who do not use spaces predominantly give a clue that they have used various tools to read the code and admit that a tab in code makes the code look bad. How bad and when? Going off the indentation, lengthy lines, different display in each OS/IDE/Editor. This means that they have used multiple tools in different environments is which is not just years of experience but exposure and adaptability to many tools. Such developers care about the code being written. It can be the perfection about the code that is maintainable, the code that is concise and expressive, the code to use nice design patterns or anything that will help manage well. When one goes an extra mile about not just working code but manageable code, it also means that they are better ones than their counterparts with similar experience who just write some code but not love code. The love part here is what makes more money.

    1. abatishchev says:

      I’m a perfectionist in code quality and I do use tabs

      1. Tez K says:

        I wonder in today’s world if someone considers themselves a perfectionist. Not to humiliate but true. You should have used a better word.

        1. abatishchev says:

          I agree that word perfectionist lost its solely positive meaning and now days has more negative tone than positive. It’s just was the first what came to my mind. It would be better to say that I consistently drive for consistency in the sake of code quality as well its maintenability, readability and supportability. Also I use tabs. The latter doesn’t contradict the former.

          1. Bart Van Leeuwen says:

            The concept of the last percent of perfection being excessively expensive compared to the first 99% of getting there has been known for a very very long time, and being a perfectionist has always had the connotation of wasting effort as well as trying to get everything right, its usually age, experience and environment and the specifics of the situation in which the word is used which make that either ‘positive’ or ‘negative’ connotation becomes more prominent.

    2. jonatown says:

      I can tell from experience that space-lovers don’t really care about the code. They often write spaghetti, they don’t adhere to a single coding style and they don’t care if they indented their code by 3 spaces instead of four… by mistake.

      1. Bryan Oakley says:

        I beg to differ. I think devs who use spaces are more about the code looking good for everyone, rather than just looking good for the original developer.

        1. jonatown says:

          I don’t think so. I’ve seen at three groups of developers doing so, in three different companies, writing completely different types of software, in various languages. And I have a lot of experience. I’d rather assume that those “space-guys” here love to give the whole group a lot of credit, where they often really just use what’s editor’s default. 😉

          I can surely agree, though, that there are developers who use spaces because they care about the code.

      2. Bart Van Leeuwen says:

        That merely suggest you need a lot more experience with different people in different environments.

        If what you state was consistently true, it would very likely offset the odd correlation the article is about.

  168. andrewh says:

    I can’t speak for anyone else, but the main reason I’ve used spaces is because I finally got tired of opening files in different editors/viewers/etc., and seeing everything spaced out in some crazy way. I didn’t want to spend the time setting “how wide is a tab when using $thing” for every single program I opened.

    Spaces look the same size (with a fixed-width font) no matter what program or page you view the code on. I don’t like surprises.

    1. Quaid Ferguson says:

      This exactly. There is no standard tab width, which causes all of your carefully aligned code to look horrible if it is using both tabs and spaces. Tabs were invented to try to trim a few characters for files sent over the phone line. Not relevant anymore.

      1. Victor Stafusa says:

        In fact, tabs were originally invented for typewriters and ported to computer keyboards later.

      2. An0nym0usC0ward says:

        Someone using tabs for indent will never mix tabs and spaces. Just like someone using spaces for indent will never mix tabs and spaces. That’s a false argument.

        1. Quaid Ferguson says:

          “Someone using tabs for indent will never mix tabs and spaces.”
          Except they do. All the time. And it is a constant source of frustration for people who want to be able to read the pull request but everything is out of alignment.

          1. An0nym0usC0ward says:

            I’ve worked on countless projects using tabs for indentation. Haven’t seen such mix in many. It happened only in projects where other problems were even bigger, i.e. when working with young, inexperienced and unskilled programmers. In such teams, spaces vs tabs are the least of your concerns.

            Usually it’s a matter of setting your preference in the editor/IDE settings once, and then never worry about it again. If you manually type each space, if your preferences say tabs for indentation, the spaces will be replaced with tabs in save. The mix only happens if your indent is already wrong.

            You got me thinking about a particular situation, however, where tabs are indeed capable to get you to mix tabs and spaces – when your coding style prescribes ASCII art. Say your coding standard says that when you break up long parameter lists you have to align the second and subsequent lines of parameters to after the opening parenthesis of the method declaration. That’s ASCII art. If you now do a refactoring and rename the method in an interface, alignment/indentation will be messed up in every class implementing that method. That’s one more reason to use tabs: you can’t prescribe ASCII art when tabs are mandatory for indentation, and have to come up with a coding style where formatting doesn’t need to change when you rename things.

  169. a r tompkins says:

    like my views on sports, music, religion, politics, and every other subject where there can be more than one opinion, which it turns out is everything, I find myself in the minority on this one too. 🙁

  170. Chris Barber says:

    You have to pay people more money to use garbage indentation formatting. Makes sense to me

    1. Robin Munn says:

      While I vastly prefer spaces because of the reasons that many other people have mentioned in this discussion thread, your comment made me grin, so have a +1.

  171. Thomas Williams says:

    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.

    1. Quaid Ferguson says:

      Is this a joke? How far are you indenting your code?

      1. Nutarama says:

        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).

        1. Quaid Ferguson says:

          So we’re talking up to 21 extra characters per line. Tops. Is that significant to anybody?

    2. 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.

      1. Thomas Williams says:

        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.

  172. Rodrigo Carvalheira says:

    intellij saves tabs as spaces… the data is not accurate…

    1. Tez K says:

      This is possible in eclipse as well. It is just a setting on usability and the actual.

    2. Bryan Oakley says:

      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.

      1. Rodrigo Carvalheira says:

        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…

  173. curtis says:

    I just found out that Mr John Daring Fireball uses tabs and that just makes me seriously happy that I use spaces.

  174. Alex Seif says:

    I think this is super mario’s fault, he put value on the spacebar with coins.

    1. James Clark says:

      Wha? Mario jumps with the A button

  175. Eihab Khan says:

    Richard Hendriks needs to see this!

  176. let's be rational says:

    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.

    1. Laurent says:

      You’re comparing spaces vs spaces mixed with tabs, not the same thing.

      1. Indentation is broken in both mixed tabs and only tabs in this case.

    2. RaymondMoul says:

      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.

      1. 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.

        1. Francesco says:

          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.

          1. Bryan Oakley says:

            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.

          2. Francesco says:

            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!

  177. Robert Lee Louviere says:

    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.

    1. Guilherme Taffarel Bergamin says:

      Elder people tend to earn more. It makes sense.

    2. gavingreenwalt says:

      I would think job experience would catch that.

      1. Guilherme Taffarel Bergamin says:

        Age is unfortunately more credited than actual experience

  178. Roman says:

    I use the space key, but I have my IDE configured so that it inserts ⅛ of a tab character.

    1. KlingOn2K says:

      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.

    2. This is just terrible. Clearly you should have it configured to insert ¼ of a tab!

  179. Morgan Grobin says:

    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.

    1. Guilherme Taffarel Bergamin says:

      That’s it, Morgan. Even though the higher salary didn’t arrive my pocket yet hehehehe

      1. Robert Lee Louviere says:

        Or it did and you’re base value is lower than you thought…. 😛

        1. Guilherme Taffarel Bergamin says:

          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.

          1. let's be rational says:

            amen to that, across all walks

    2. let's be rational says:

      spot on. reflects my thinking exactly.

    3. 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.

      1. Nutarama says:

        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.

        1. > 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.

      2. Bryan Oakley says:

        “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.

    4. cageordie says:

      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.

      1. Morgan Grobin says:

        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.

        1. cageordie says:

          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.

    5. jonatown says:

      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.

    6. Robin Munn says:

      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.

    7. beets says:


  180. Operating Thetan says:

    Have fun with your Makefiles then.

    1. Stijn van Drongelen says:

      If you’re willing to use backslashes and semicolons, Makefiles work fine without tabs.

    2. A says:

      My vim automatically inserts tabs if I’m editing a Makefile, otherwise tab is 4 spaces.

      1. Operating Thetan says:

        I don’t use Vim. I use a modern IDE that does the same but without the feeling of living in the 80’s.

    3. Andy says:

      You got me. I get paid more than you to write code I don’t know how to build…

    4. Bryan Oakley says:

      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.

      1. Operating Thetan says:

        It seemed obvious to me that I was making a joke and that everyone would understand it.

        1. Bryan Oakley says:

          tabs vs spaces is not a joking matter. This is serious stuff! 🙂

          1. Operating Thetan says:

            People are at war because of Vim vs Emacs! 🙂

          2. Bryan Oakley says:

            All I can say is, when deciding about tabs vs spaces, THINK OF THE CHILDREN!

  181. Lex Irons says:

    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.

    1. Abi Gail says:

      There are still people who manually indent?

      For over two decades, I’ve been using editors which know when to indent. Or de-indent.

      1. Guilherme Taffarel Bergamin says:

        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.

      2. “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.

  182. handleym says:

    “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.

    1. Laurent says:

      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

      1. 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.

      2. Andy says:

        You’re making a straw man argument… exactly the kind of logical fallacy a tabs programmers make all the time… 🙂

  183. Brett Davis says:


    1. *meanwhile in normal editor/ide* [tab] -> 2 spaces so doesnt matter. 😀
      Using notepad can take more time.

  184. Axel Heider says:

    So, now we need this correlated with Vi vs. Emacs…

  185. cb75075 says:

    Its also directly correlating with shark attacks.

    1. Xoly says:

      Not even attacks – just correlates directly with sharks.

  186. Will says:

    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.

    1. Yes. Low paid devs don’t understand their tools.

    2. Laurent says:

      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?

  187. Maxxon says:

    Ahhh, but did you think that those ppl who use spaces are more likely to lie? 😉 😀

  188. GonzoI says:

    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.

    1. let's be rational says:

      or are lazy.

  189. Ritesh Rituraj Nayak says:

    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.

    1. Stella Orion says:

      Will you marry me?

      1. Ritesh Rituraj Nayak says:

        I’d love to!

        1. Stella Orion says:

          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

    2. Dylan James Wagner says:

      Leading whitespace tabs, internal line whitespace spaces, this keeps your formatting and allows your editor to size the tabs how ever it is configured.

      1. 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.

        1. Dylan James Wagner says:

          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.

      2. 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.)

        1. Francesco says:

          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.

          1. 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.

          2. Francesco says:

            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)

          3. 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.

          4. Francesco says:

            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.

        2. Dylan James Wagner says:

          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.

          1. 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.

          2. Dylan James Wagner says:

            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.

          3. “[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.

  190. Baris Ozkuslar says:

    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.

    1. Bryan Oakley says:

      “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.

  191. Kevin Norris says:

    > 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…


    > 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.


    1. David Robinson says:

      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: ). 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?)

      1. Kevin Norris says:

        I made pessimistic assumptions in order to demonstrate the robustness of your result, not to criticize it.

        1. David Robinson says:

          Sure, but you did call it sloppy 😉

      2. Guilherme Taffarel Bergamin says:

        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.

        1. let's be rational says:

          your cynicism runs deep.

          1. Guilherme Taffarel Bergamin says:

            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”.

          2. let's be rational says:

            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.

          3. Guilherme Taffarel Bergamin says:

            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.

          4. John says:

            What is illogical about it?

          5. Guilherme Taffarel Bergamin says:

            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”

          6. Guilherme Taffarel Bergamin says:

            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

  192. Ralf Kleberhoff says:

    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.

  193. Arnold Spence says:

    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.

    1. Nikhil Sahu says:

      Finally someone said it.

    2. 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.

  194. Colz says:

    You’re missing a variable prob

    1. David Robinson says:

      Code and data are here, try it out!

      1. And, dare I say it?, have a look at the `tab_space_survey` function in the sample code in `` and consider the effect of tabs vs. spaces on that.

        1. David Robinson says:

          tab_space_survey is an object, not a function. I’m not sure what you’re referring to?

          1. Sorry, I don’t know R and I didn’t read too closely. Whatever that thing is on the line starting tab_space_survey through the line starting filter(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.)

  195. Typing spaces just takes more time, thus per/hour it is more expensive. That simple 😊

    1. JadePenguin says:

      Many editors such as PyCharm do spaces automatically when you hit TAB key

      1. John says:

        Yes. Pretty much _all_ editors and IDEs which any real programmer would use, allow this to be configured.

      2. All modern editors do this. Every single one.

    2. Félix Gagnon-Grenier says:

      …. you really think people use the space key to insert the spaces?

      1. el.dide says:

        … you really think this was not a joke ?

        1. Félix Gagnon-Grenier says:

          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…

    3. ryepdx says:

      I don’t think anyone who uses spaces over tabs types the spaces individually. The IDE does it automatically for you.

      1. GonzoI says:

        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.

        1. Félix Gagnon-Grenier says:

          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.

          1. GonzoI says:

            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.

          2. ozzy says:

            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.

          3. Brian Christensen says:

            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.

          4. 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.

        2. ryepdx says:

          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.

          1. GonzoI says:

            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.

        3. Guilherme Taffarel Bergamin says:

          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

          1. GonzoI says:

            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.

          2. Guilherme Taffarel Bergamin says:

            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

          3. Ext3h says:

            [code]char *foo = (

            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.

          4. Ext3h says:

            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.

          5. GonzoI says:

            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,

            EDIT: Forgot that I’m on the internet where spaces aren’t rendered…

          6. Ext3h says:

            If you need to break one, then break all.

            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.

        4. Nick Brown says:

          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.

          1. GonzoI says:

            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.

          2. Nick Brown says:

            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.

          3. GonzoI says:

            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.

          4. Nick Brown says:

            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.

          5. 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.

          6. 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.

          7. k says:

            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.

          8. GonzoI says:

            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.

        5. > 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.

    4. BlueNinjaSmurf says:

      Configure your editor right and there is no extra time. Also, spaces maintain consistent visual styling across development tools.

  196. mingos says:

    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.

    1. 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.

      1. An0nym0usC0ward says:

        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.

  197. Matteus Deloge says:

    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 …

    1. David Robinson says:

      See the first graph; the effect exists within each level of years of experience.

    2. Nick says:

      Dude did you even read the article? Years of experience was literally the FIRST confounding factor that they controlled for.

      1. Matteus Deloge says:

        Totally blew past that, I guess I need to refill my cup of coffee big time. Apologies

        1. anonymous says:

          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

          1. John says:

            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.

  198. Mike Darkins says:

    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.

    1. Félix Gagnon-Grenier says:

      … 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”.

    2. It’s a very reasonable explanation, supported by the evidence.

  199. Josue Ibarra says:

    I automated that promotion for those that are interested 😉

  200. Bill the Lizard says:

    Clearly employers are paying developers by the byte.

    1. Félix Gagnon-Grenier says:

      Me own bytes go to eleven.

  201. Mike Lemmon says:

    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.

    1. Cory Long says:

      Or only very few people answered go and spaces, and so the sample size in that specific case is small.

    2. Tim! says:

      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.

    3. Throstur T says:

      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.

      1. Peter Williams says:

        Is having to use vi worth the higher salary?

  202. Andrew Maxwell says:

    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.

  203. Marco Ko says:

    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.

  204. Marco Ko says:

    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.

  205. Jay says:

    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.

    1. GonzoI says:

      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.

    2. Guilherme Taffarel Bergamin says:

      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.

  206. Opslag Medium says:

    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…

    1. Guilherme Taffarel Bergamin says:

      I don’t know which IDE you use, but I’m pretty sure you can use it to autoindent…

    2. Chad Hansen says:

      Most IDEs nowadays will have an automatic document formatter. Configure it properly with your team’s standards and never worry about code styles again.

      1. John says:

        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.

        1. Guilherme Taffarel Bergamin says:

          Just out of curiosity… Why would anybody not use an IDE?

          1. Nutarama says:

            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.

          2. Guilherme Taffarel Bergamin says:

            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.

          3. Nutarama says:

            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.

          4. An0nym0usC0ward says:

            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.

          5. An0nym0usC0ward says:

            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.

          6. anonymous says:

            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)

          7. John says:

            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.

          8. An0nym0usC0ward says:

            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).

          9. John says:

            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.

  207. Guilherme Taffarel Bergamin says:

    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.

    1. GonzoI says:

      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”.

      1. Guilherme Taffarel Bergamin says:

        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.

        1. GonzoI says:

          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).

          1. Guilherme Taffarel Bergamin says:

            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

  208. tuba.terry says:

    This is all self-reported, yes? What if the conclusion is spaces developers are just inflating their salaries by 8.6%? [trollface]

  209. Robert Boehne says:

    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.

    1. GonzoI says:

      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.

  210. rmonster says:

    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.

    1. Guilherme Taffarel Bergamin says:

      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.

    2. Zapados says:

      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.

      1. Zapados says:

        And of course that was a typo….
        “People using SPACES work at larger companies and therefore make more money.”

    3. John says:

      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 🙂

  211. Chip Overclock® says:

    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.

    1. Luna says:

      They disappear when its minified.

    2. GonzoI says:

      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.

      1. Guilherme Taffarel Bergamin says:

        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…

        1. GonzoI says:

          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.

          1. Guilherme Taffarel Bergamin says:

            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

          2. GonzoI says:

            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.

          3. Guilherme Taffarel Bergamin says:

            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…

  212. Erno says:

    It’s simple. Programmers get paid per character.

  213. Red Cricket says:

    Maybe developers that use spaces exaggerate.

    1. Paulo Reichert says:

      You’re probably right as we all know you can’t trust developers that use spaces.

  214. Chris G. says:

    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’.

    1. Félix Gagnon-Grenier says:

      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….


      1. Adam Jorgensen says:

        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.

        1. Stephen Ostermiller says:

          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.

          1. Adam Jorgensen says:

            If you genuinely think ambiguity is a feature then I can only conclude you’ve never had to work with timezones and DST transitions 🙂

    2. NoSir says:

      do you even read? medians differ

      1. Chris G. says:

        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.

  215. Marijana Larma says:

    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.

  216. stamsarger says:

    Biggest bullshit I’ve ever read

    1. Kyle Strand says:

      Sounds like you must be a tab user. BURN THE HERETIC!

      1. GonzoI says:

        If you insist, heretic. Stand still.

    2. Félix Gagnon-Grenier says:

      dude… calm down.

    3. Marco Ko says:

      that’s exactly the intention of the author – using the temptative conclusions of an association study to teach sth else. it’s satirical..

  217. 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.

    1. Klaus Stock says:

      Ctrl+Z, pkill -9 vi 😉

      1. Craig Allen says:

        Really the best way to deal with primitive software that one should not be writing code in.

        1. Some of the best devs on the planet use vim. It’s a badge of honour.

          1. John says:

            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.

          2. Craig Allen says:

            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.

          3. John says:

            That’s fine for lazier people, but acting like you can iterate faster by preferring them to vim is just dishonest.

          4. Craig Allen says:

            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.

          5. 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.

          6. 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.

          7. commenter says:

            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.

          8. KlingOn2K says:

            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.

      2. Turn it off and on again.

    2. Anonymous Coward says:

      Did you just assume how many spaces I use for tabs?!

      1. John says:

        Is that like assuming your gender?

    3. Tristan Hyams says:

      4 spaces for Windows devs.

    4. “Here’s a nickel kid, get yourself a real whitespace character.”

    5. :!sudo shutdown -P now

  218. Potato says:

    Great! Meanwhile blocker bugs in the SO/SE sites are well and alive! Way to go!

    1. Adam Lear says:

      One of these days we’ll convince our data scientists to stop looking at data and fix bugs instead. Don’t give up hope!

      1. Jerry Coffin says:

        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).

        1. Félix Gagnon-Grenier says:

          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…

      2. Nutarama says:

        You have enough work to justify the salaries of more than one data scientist?

    2. Layton Miller says:

      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?


  219. Billy Hinners says:

    Maybe the title of this article should be “Developers who use spaces more likely to exaggerate salary claims”?

  220. Sheikh Heera says:

    So, one who uses space instead of tabs makes more money!!! How is this logical?

    1. Klaus Stock says:

      The coice of programming language influences the decision of spaces vs. tabs.

      1. Kyle Strand says:

        The author adjusted for that.

    2. Kyle Strand says:

      “…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.

  221. sheanmassey says:

    also.. fwiw:

    set tabstop=4
    set expandtab
    set softtabstop=4
    set shiftwidth=4

    End of discussion.

    1. Corey Wischmeyer says:

      I added this to my vimrc and my boss just bumped my salary! Thanks!

      1. jbw says:

        Ctrl+v -> tab -> outputs a tab character regardless of the above config in vim. TMYK

      2. sheanmassey says:

        Me too! 🙂

      3. graywh says:

        Thankfully, vim’s default Makefile config unsets ‘expandtab’.

        1. Red Cricket says:

          cool! didn’t know that.

    2. Rörd Hinrichsen says:


      (set-default ‘indent-tabs-mode nil)

  222. Adam Patterson says:

    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”.

  223. sheanmassey says:

    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.

    1. Jacob Stamm says:

      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?

      1. John Reno says:

        I think he’s saying that as soon as one developer on the team decides to use spaces then everyone is forced to.

        1. Nitin says:

          Forced to explain to that one developer that they’re part of a team?

      2. sheanmassey says:

        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

        1. Jacob Stamm says:

          What do those settings mean for those of us who aren’t Linux vim programmers?

          1. sheanmassey says:

            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.

      3. Evan Sullivan says:

        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.

  224. Dennis Hort says:

    Take THAT Richard Hendriks!

  225. elastic tabstops ftw

    1. Kyle Strand says:

      If only, if only, if only….

  226. Jack Johansson says:

    “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

  227. Sagar Tanur says:

    Tabs are good. I can’t agree with this post

    1. Iron Sean says:

      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.

    2. Kevin Smith says:

      The article makes no claims about the technical merits of tabs vs spaces. It just points out the existence of a correlation.

  228. TechUser2011 says:

    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.

    1. CeeBee says:

      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”.

    2. tuba.terry says:

      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.

    3. rumtscho says:

      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.

    4. TennSeven says:

      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.

      1. TechUser2011 says:

        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).

        1. TennSeven says:

          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…”

  229. jr1 says:

    opinionated and irrelevant. also incorrect findings.

    1. mmmpop says:

      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).

    2. Dave says:

      What are the correct findings?

    3. Kyle Strand says:

      Also, what’s the “opinion” being presented here? The author is presenting data and even states that the results are “surprising” and unexpected.

      1. Joshbeast says:

        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.

        1. Kyle Strand says:

          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.

  230. Martijn says:

    What of developers who mix tabs and spaces? 😛

    1. Kevin Smith says:

      They are to be exiled to a horrific world where the only language available is PHP and the only editor is ed.

      1. jr1 says:

        the only language should be something worse…

        1. sheanmassey says:


        2. Kevin Smith says:

          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.

      2. CeeBee says:

        Or JavaScript.

    2. Vrae says:

      It actually describes people who replied “Both” as being indistinguishable to just tabs.

      1. Martijn says:

        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).

    3. Jimmy says:


      1. Martijn says:

        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.

    4. Iron Sean says:

      It’s referenced right there in the very first graph and paragraph. You really didn’t read, did you…

      1. Peter Graham says:

        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.

      2. Martijn says:

        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).

  231. RadthorDax says:

    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.

  232. minus Seven says:

    I would have expected better from stackoverflow.
    There is no reason given in the article to explain why.
    Correlation is not equal to Causation.

    1. Scott Lavigne says:

      Did you even read the conclusion?

    2. s73v3r says:

      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.

    3. Mike says:

      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.”

    4. Peter Graham says:

      It says Correlation is not Causation in the conclusion. This is an interesting and amusing article and that’s all.

  233. Dave Dyer says:

    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 🙂

    1. Kyle Strand says:

      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.”

  234. figital says:

    The HTML in this clickbait is tabbed with tabs.

    1. Mike says:

      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!!!”

      1. Michael Clark says:

        “Google Developers hate him! Learn how he increased his salary with this one little trick!”

    2. Daniel Hug says:

      They actually mix tabs and spaces.

  235. Shirish says:


  236. Lynx says:

    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.

    1. vim says:

      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.

      1. jr1 says:

        lol explain this to my boss who is unapologetically a tabs man.

    2. sosiosh says:

      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.?

    3. TennSeven says:

      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.

  237. camainc says:

    I’m a 32nd Degree Master Tabster

    1. RagnarDanneskjöld says:

      I scrolled down to post this same xkcd : ))

    2. Mike says:

      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.”

      1. TheBox193 says:

        Did read, and I recognize the author recognizes that as well as did statistical effort to explore the dat. Still funny. 😉

      2. 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.

    3. Joshua says:

      Fun joke. Not relevant here. The author was clear that correlation != causation. Several times.

  238. Mark Lapasa says:

    I tried using Spaces once, it was awful

    1. Marios Santamaria says:

      my salary kept increasing beyond control, I eventually had to go back to tabs

  239. commenter says:

    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.

    1. Kostya Pogromskiy says:

      This assumption is controversial to the first chart.

      1. commenter says:

        How? Please explain.

        1. Kostya Pogromskiy says:

          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.

          1. commenter says:

            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.

    2. Noel Hibbard says:

      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.

    3. tuba.terry says:

      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…

    4. msg says:

      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.

      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.”

  240. Alex Artushin says:

    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.

    1. Iron Sean says:

      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.

  241. Frank says:

    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.

    1. Bryan Oakley says:

      If you’re optimizing for source code file size, you’re doing something wrong.

    2. Not Projecting says:

      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.

      1. RadthorDax says:

        Or indeed *how many* ASCII characters.

  242. Samuel says:

    I used tabs but configured my editor to put 4 spaces…

    1. Bryan Oakley says:

      So, you don’t use tabs. You use the tab _key_, but you don’t use tabs.

      1. Chris G. says:

        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.

  243. Félix Gagnon-Grenier says:

    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…

    1. CeeBee says:

      We don’t. Check the other responses to see some space users *actually do* that.

      1. Félix Gagnon-Grenier says:

        no, they don’t, except in a tv show.

        1. CeeBee says:

          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.

          1. Paul Ishak says:

            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.

          2. CeeBee says:

            How? Spaces cause problems when reusing code,