Developers Who Use Spaces Make More Money Than Those Who Use Tabs

Do you use tabs or spaces for code indentation?

This is a bit of a “holy war” among software developers; one that’s been the subject of many debates and in-jokes. I use spaces, but I never thought it was particularly important. But today we’re releasing the raw data behind the Stack Overflow 2017 Developer Survey, and some analysis suggests this choice matters more than I expected.

Spaces make more money than tabs

There were 28,657 survey respondents who provided an answer to tabs versus spaces and who considered themselves a professional developer (as opposed to a student or former programmer). Within this group, 40.7% use tabs and 41.8% use spaces (with 17.5% using both). Of them, 12,426 also provided their salary.

Analyzing the data leads us to an interesting conclusion. Coders who use spaces for indentation make more money than ones who use tabs, even if they have the same amount of experience:

Indeed, the median developer who uses spaces had a salary of $59,140, while the median tabs developer had a salary of $43,750. (Note that all the results were converted into US dollars from each respondent’s currency). Developers who responded “Both” were generally indistinguishable from ones who answered “Tabs”: I’ll leave them out of many of the remaining analyses.

This is an amusing result, but of course it’s not conclusive by itself. When I first discovered this effect, I assumed that it was confounded by a factor such as country or programming language. For example, it’s conceivable that developers in low GDP-per-capita countries could be more likely to use tabs, and therefore such developers tend to have lower salaries on average.

We could examine this by considering whether the effect occurs within each country, for several of the countries that had the most survey respondents.

The effect is smaller in Europe and especially large in India, but it does appear within each country, suggesting this isn’t the sole confounding factor.

As another hypothesis, we know that different types of developers often use different indentation (e.g. with DevOps developers more likely to use spaces and mobile developers more likely to use tabs), often because they use different editors and languages. The Developer Survey asked both about what programming languages each respondent uses (Python, Javascript, etc) and what “type” of developer they are (web developer, embedded developer, etc).

Did we see the same tabs/spaces gap within each of these groups?

Yes, the effect existed within every subgroup of developers. (This gave a similar result even when filtering for developers only in a specific country, or for ones with a specific range of experience). Note that respondents could select multiple languages, so each of these groups are overlapping to some degree.

I did several other visual examinations of possible confounding factors (such as level of education or company size), and found basically the same results: spaces beat tabs within every group. Now that the raw data is available, I encourage other statisticians to check other confounders themselves.

Estimating the effect

If we control for all of the factors that we suspect could affect salary, how much effect does the choice of tabs/spaces have?

To answer this, I fit a linear regression, predicting salary based on the following factors.

  • Tabs vs spaces
  • Country
  • Years of programming experience
  • Developer type and language (for the 49 responses with at least 200 “yes” answers)
  • Level of formal education (e.g. bachelor’s, master’s, doctorate)
  • Whether they contribute to open source
  • Whether they program as a hobby
  • Company size

The model estimated that using spaces instead of tabs is associated with an 8.6% higher salary (confidence interval (6%, 10.4%), p-value < 10^-10). (By predicting the logarithm of the salary, we were able to estimate the % change each factor contributed to a salary rather than the dollar amount). Put another way, using spaces instead of tabs is associated with as high a salary difference as an extra 2.4 years of experience.

Conclusion

So… this is certainly a surprising result, one that I didn’t expect to find when I started exploring the data. And it is impressively robust even when controlling for many confounding factors. As an exercise I tried controlling for many other confounding factors within the survey data beyond those mentioned here, but it was difficult to make the effect shrink and basically impossible to make it disappear.

Correlation is not causation, and we can never be sure that we’ve controlled for all the confounding factors present in a dataset, or indeed that the confounders were measured in the survey at all. If you’re a data scientist, statistician, or analyst, I encourage you to download the raw survey data and examine it for yourself. You can find the code behind this blog post here if you’d like to reproduce the analysis. In any case we’d be interested in hearing hypotheses about this relationship.

Though for the sake of my own salary, I’m sticking with spaces for now.

Author

David Robinson
Data Scientist

Related Articles

Comments

  1. Keith Hultman says:

    That is quite an interesting result. The fact that it is found in every language is impressive. As a tab user, I don’t think switching to spaces will have an effect on my salary or job prospects as I think the confounding variable here is probably coder personality and attention to detail. Did you look at age?

    1. “I think the confounding variable here is probably coder personality and attention to detail.”

      ^^^ This.

      And also: experience with source control and collaboration.

      1. Interestingly, the author claims that experience is considered to be a confounding variable. Can you gain experience, yet, as a lone programmer? Perhaps, so this is a great point about collaboration. It’s usually when you collaborate you find out that your tab-settings are incompatible with other people’s settings, because they either use spaces, or a different indentation settings for tabs.

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

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

    2. I’ve certainly never been asked if I use tabs or spaces during an interview. Or after I was hired. Or really in any context other than the online holy war…

    3. I think it’s more likely that spaces are just more prevalent in a certain type of commercial environment that also happens to pay higher salaries.

    4. Did anyone check the company pay scale v documented coding styles?

      Anecdotally, larger and/or older companies are more likely to have a documented and enforced coding style, and most of those I’ve seen use spaces. They do this for the obvious reason of consistency (ie: lack of flexibility and variation) which tends to be more important in such places.

      I think it’s interesting in that personal preference (or so I’ve seen) tends to be tabs. In situations where the coder is considerably less concerned with other coders (ie: self-centered).

      I’m wiling to bet (not a lot, though) that those who have changed from one to the other have changed between those environments.

      Get high paying job at “BigCo”, switch to spaces and drink kool-aid™. Join a small start-up or do your own coding, switch to tabs and drink too much espresso (“office” being a cafe).

      Just a thought (and possibly not a good one) based 45 years of ops & dev.

  2. Eric Hydrick says:

    Did you look at number of languages space vs. tab users know and/or use? I’d imagine being a polygot would command a higher salary, and it’s possible space users tend to know more programming languages than tab users.

    1. With all the different languages I work with, I use spaces because they’re consistent across all editors. Tabs are not.

      When you open an editor and see a mixture of tabs and spaces, all the code can be out of whack. Tabbed spacing also wreaks havoc when the editor does code clean-up or comparison for code reviews.

      Using a specific number of space characters represents consistency and intentionality, which I suspect reveals more about the personality of the person doing the work. Tabs might be faster, but they’re sloppy. You don’t know what tools your other team-mates will use five years down the road when they have to read your code.

  3. Vidhyashankar Madheswaraswamy says:

    I guess we need to look the other way. Developers who earn more ( are obviously Good at what they Do), Prefer spaces than Tabs. This can be inferred that better programmers prefer spaces.

    1. > Developers who earn more (are obviously Good at what they Do).

      This is a very poor deduction.

    2. Nick Odaemus says:

      You *can* infer that, but it’s foolish. There are so many personality factors behind those two statistics! Developers who earn more ≠ better programmers; they may earn more
      based on their assertiveness with raises and beginning salary alone, which has nothing to do with their programming quality.

  4. Václav Haisman says:

    Spaces master race!

    1. We can do without the Nazi references thank you,

      1. It’s actually a Zero Punctuation reference, interestingly enough.

        1. Which was a reference to . . .

      2. Václav Haisman says:

        lol, it is not a Nazi reference. Know your meme.

  5. Isn’t it more likely that older developers who are locked in their ways use spaces, and since they are older they are more experienced since they have been developing longer and thus make more money in general. Like in decades past you could probably say people who smoke make more money.

    1. No. The very first chart is about years of experience.

      1. Years of experience; Not age.

    2. Victor Lewis says:

      Check the x axis

    3. Read the article – not the headline 🙂

    4. Read the article. The very first graph plots age, and it starts out with spaces over tabs, and continues. Nothing to do with older age. Plus, a modern PHP developer who has adopted the PSR coding standards isn’t “locked in their ways”; it’s a prevalent coding standards that’s become widely-adopted.

  6. All professionals know that you cannot write source code that contains tab symbols, because such
    code will always turn into an unreadable mess whenever exported (for example when posted on SO). Therefore all professionals tend to know that you configure your text editor to insert spaces upon tab, which tends to be the default setting in almost every IDE out there. Then you can indent by pressing the spacebar or by pressing the tab key and it doesn’t matter. Assuming you know these things, the question “tabs or spaces” doesn’t even make any sense.

    1. unless you also configure your IDE to magically delete 4 spaces on pressing backspace after an IDE inserted 4 space block, there’s serious chances of messing up the formatting of your code. This risk goes even bigger if you have junior devs working on the codebase.

      1. How? Most editors don’t delete 4 spaces but 1 when you press backspace. You will have to be pretty damn oblivious to your own source code if you don’t notice that the marker isn’t where you want it to be. Really, this whole “tab vs spaces” is a non-issue that doesn’t exist. All professional source code out there that uses space tokens, because insert-space-upon-tab is industry standard. I have no idea why I am the only one raising this question… nobody else used a source code editor before?

        1. I’m with you on tab’s converting to spaces 😀

          Jetbrains IDE’s delete 1 space upon backspace, and depending on coding style, will insert 2 or 4 spaces upon tab.

          You can then remove the indents by using shift+tab.

          After selecting multiple lines you can indent / unindent as much as you like with tab. pressing space just deletes the block of code.

          Maybe these anti-tab people are still using vi / notepad that keeps tabs as tabs?

          1. The “anti-tab” people do the same thing as you (e.g., I use vim and it also can insert spaces on tab, just like most IDEs can insert “soft tabs”). We frequently press the tab key just like normal people, we just want that to map to spaces, not tabs. On the other hand, the pro-tab people use actual tabs, that is the 0x09 character, in their code.

          2. Ah okay thanks. I prefer spaces, and will generally swap any tabs I find over to spaces.

            I think there is some crossover in the discussion on this page about use of Tab key vs actual tabs in code. In general it seems fine to use the tab key, providing it maps to spaces.

        2. What terrible editor is this?! Most/all editors I’ve encountered are configurable to have backspace undo one level of tab indentation, even when tabs are converted to spaces.

          The last time I can remember an editor didn’t do this was ~ a decade ago.

        3. Edwin Kravčenka says:

          Sublime deletes all tab spaces together by default when u have tab translation into spaces. Also *all* good editors can programmed to do nearly anything you want.
          Pretty sure Vim also deletes tab spaces.

      2. shift+tab will undo the spaces inserted with tab.

        Also, don’t most IDE’s have an option to auto format code?

    2. Bryan Oakley says:

      This sounds like a “No true Scotsman!” argument.

      1. Not really, because “no true Scotsman” assumes that the arguments are subjective. “Professional programmer” is a level of skill acquired through experience. Everyone who is experienced have exported code and viewed it in a different editor. This is not subjective – of course every programmer will eventually end up using different editors. Upon doing so, anyone with eyes will notice that code indented with tabs turns into a horrible mess. This is not subjective, it is a simple fact, since different editors have different tab settings. Upon noticing this, people who indent by using the tab key eventually starts configuring their editors to insert spaces. Programmers who have interacted with other programmers will know from experience that this is a phase that most programmers go through as part of learning. This leaves us with 3 categories: inexperienced programmers who indent with tab key to insert tab symbols, experienced programmers who indent with tab key to insert spaces, and programmers (no matter level of experience) who indent with spacebar to insert spaces.

        1. Jimmy Jim says:

          All professionals know that simply having different tab settings doesn’t turn code into a horrible mess. Tab settings usually just change the spacing of each indention level. Exactly the same effect they have when converting tabs to spaces.

    3. Kyle Strand says:

      I know multiple experienced, professional coders who know all of the above and nevertheless prefer tabs.

      Heck, I believe Linus mandates tabs in the Linux kernel.

      I disagree with the preference for tabs, but that doesn’t mean it’s only endorsed by the ignorant or inexperienced.

  7. I was expecting that people who use both make much less money…

  8. As someone who started with tabs and quickly switched to spaces ~15 years ago, I think it’s something much more trivial that’s often frowned upon when source control is involved, but that makes certain parts of code far more readable: Using spaces to align similar statements. It’s much harder to do consistently when tabs are involved. I can easily see that extra readability leading to a jump in productivity, though I wouldn’t expect that much.

    1. this. however, this is the core argument in the “tab v space” holy war, and as such, it won’t convince anyone.

      space argument: this

      tab argument: this is irrelevant, your IDE/text editor can translate these alignment issues transparently. This isn’t 1995 anymore.

      I’m in the “spaces” camp, btw

      1. Pluckerpluck says:

        > your IDE/text editor can translate these alignment issues transparently.

        Spaces always require you to use multiple arrow key presses to move through them. Tabs are a single key press. This isn’t important if you are a vim god I guess though.

        Or when doing work collaboratively, the last thing you want to be doing is changing the indentation size of spaces (causes chaos with alignment cases), yet tabs let you do this visually without affecting anything else.

        Just pointing out that the translation is not quite transparent. There are still differences.

        1. ctrl/cmd+arrow makes short work of travelling through any indentation or even white space, regardless of type (though I personally find Mac deals with this in a terrible fashion).

          1. And vim uses w (for “word”) and b (for “back”) to do the same – jump a text word and its trailing whitespace at the same time in a single keystroke.

        2. this is why i always use spaces

      2. I’m not talking about the beginning of the line, though. I’m talking about in the middle of the lines. For example, aligning assignments or dictionaries into columns, or a related-but-not-abstractable series of function calls or math statements, to make it far easier to just scan down.

        If people could easily stick to Pluckerpluck’s tabs-for-indentation/spaces-for-alignment way of doing it there wouldn’t be much of an issue. But inevitably, tab-users will use tabs to do those alignments, and that’s when it quickly gets all out of whack.

        1. well… idk about “IDEs” but vim can handle this use case

          still, spaces are the only real way to code

        2. I’ve been arguing for Tabs for Indentation, Spaces for Alignment for years, but.. too many people see it as an all-or-nothing approach, probably since not thinking about it means they can concentrate on other details.. or their 3D printer breaking again.

    2. Pluckerpluck says:

      I prefer tabs for a variety of reasons, but there is ONE aspect I dislike which is aligning statements. Normally I would just say that you should use tabs for indentation, spaces for alignment. The problem is that people suck though and screw this up ALL THE TIME. If people just used tabs for indentations and spaces for alignment it would all work, but alas, that’s not the world we live in.

      My solution is to newline the stuff I want to align. Took a while to get used to, but I think it’s optimum:


      if (longComplexThing && otherComplexThing && finalComplexThing) {

      becomes


      if (
      longComplexThing &&
      otherComplexThing &&
      finalComplexThing) {

      Lets me use the glorious tabs but still ensure code compatibility with all the crazy people who can’t follow a set of coding guidelines.

    3. I learned long ago you wouldn’t want to align with tabs, but that doesn’t mean you can’t use tabs for indentation. I suppose in the end making such a distinction is too painful when your IDE doesn’t do it and you can just hammer tab a few times to align instead.

      1. Bryan Oakley says:

        If you use tabs for indentation and spaces for alignment, how do you handle the case where different tab widths break the alignment?

        1. They don’t. When would you align things on different indentation levels? That’s insanity regardless of if you use tabs or spaces. Using Pluckerpluck’s example below: under TISA that would be spaces, not tabs.

  9. I’d imagine the real predominant factor here is what kind of coding styles prevail where each of those programmers work (since I’d imagine that eventually this would influence what said programmers get accustomed to using, and hence “skewing” the results here). That would also probably show up some other patterns in common rather than spaces vs tabs.

    1. This seems like a good hypothesis. To pick on marketing firms and programmers who work for them, I would have to guess these are the low bar jobs from my experience in working in many different organizations in terms of rigor. The enforcement of structure is much more relaxed and code reviews are practically unheard of compared with a software shops that typically pay more. Code shops tend to use spaces over tabs as it tends to work better in command line editors such as vim and then look good on github as well. Try having tabs on github. It sucks.

      1. Brian Christensen says:

        .editorconfig in your repository root specifying your preferred indent_size for display on GitHub easily solves that.

    2. Thanks for actually paying attention 🙂

  10. Tabs are for word processors not IDEs

  11. GrandOpener says:

    Are median salaries in Germany and UK really *half* what they are in the US? Maybe this is something I should already know, but that was the most surprising revelation here to me.

    1. Thomas Peeters says:

      Perhaps related to the differences in income taxation?

    2. No, Americans are more likely to lie about how much they earn. Cela explique tout.

      Surveys are notorious for having people answer what they think should be the right answer.

      That means that a bunch of responses will be conditioned on the fact that Richard from ‘Silicon valley’ uses one or the other (I forget which – I’m a Guilfoyle… I do things that matter, so I have no time for trivial nonsense… he said, typing a comment on the internet – in my own defense, it’s 12:30 a.m. here and I am having a glass of wine having almost finished a project report that was due a week ago).

      People with nothing better to do need false dichotomies so that they can pick a side and belong. It’s been that way since the Blues vs Greens in Byzantium, and probably before. Anyone who wants to belong to either side of a pointless dichotomy needs to die in a fire.

      1. Hm. Gross salaries for developers in the US are vastly higher than in Germany and the UK. Maybe not 2× but from the numbers on starting salaries (!) that I’ve seen, 2× actually isn’t terribly far off.

        Lying about salary might be another factor but it’s minor compared to the actual, real salary difference. Of course this also differs within the US (Bay area …) but even the mean is higher.

      2. Americans are more likely to lie.. as you sip on kool-aid calling it wine. Irony…

  12. Maybe the space users have more of a ‘i don’t care if it is theoretically correct, it works’ attitude and therefore more of them have a job in a larger company which pays better?

    1. You’re probably a tabber!

      1. I doubt that you are one 😉

  13. Marlon Stevenson says:

    Maybe people who use spaces are more likely to overreport their earnings, because they also overcompensate on the lack of control in their lives by repeatedly mashing the spacebar.

    1. Do you actually think people who use spaces for indentation press the spacebar for every level indentation that they want? Because that’s not the case, you just configure your editor to use spaces for indentation, to convert tabs to spaces. So when I hit Cmd+] or Tab, it inserts or removes 4 spaces. When I go to a newline it inserts the relevant number of spaces.

      1. then what’s the point of using spaces if you are already pressing the tab key?

          1. Sven Slootweg says:

            Worth noting that PEP-8 was never meant to be used for anything outside the Python standard library. There’s no reason to adhere to it in your own code, and there’s no technical rationale behind [many of] its recommendations.

          2. Being consistent with every other Python project is a good enough reason for me. The tooling around it makes compliance very easy.

          3. Bryan Oakley says:

            While I absolutely hate using whitespace rather than curly braces to denote a block of code, it is far, far outweighed by the fact that most python code looks the same since we mostly all share the same set of guidelines.

        1. 1 – You can align text with finer granularity. For instance if I place a line break in a comma delimited list, the editor can align the list vertically with the resolution of a single whitespace, not 2, 4 or 8

          2 – The code looks the same no matter what the local tab size setting is

          1. That makes no sense. Tabs are only meant for indentation; You would use spaces either way for alignment. Tabs for Indentation, Spaces for Alignment.

        2. Bryan Oakley says:

          the point of using spaces is so that the next person who looks at your code sees it the way you intended it to be seen.

      2. Bryan Oakley says:

        I’ve seen one programmer in this discussion who claims that do that. I can’t imagine why.

      3. Marlon Stevenson says:

        Maybe people who use spaces are not developed enough to understand humor.

    2. Tabber!!!

  14. Perhaps programmers using spaces lie more about their salary.

    1. Félix Gagnon-Grenier says:

      Found the old school tab user 😉

      1. The trend is the opposite. I find it amusing when people say “Who
        still uses tabs?” — Tabs are more flexible and a *proper* understanding
        of them (and TISA) is only starting to emerge.

        1. Félix Gagnon-Grenier says:

          I have yet to find a single “more flexible” thing one can do with tabs that I can’t do with any code reformatting tool…

          1. Not having to commit it. The moment you bring up a code reformatting tool, it doesn’t matter which side you’re on as the whole debate becomes moot: You pick one, and the one wielding the reformatting tool makes it happen. Period.

          2. Félix Gagnon-Grenier says:

            Ahhh…! I believe I just now understood. I never considered the firm “without code reformatting” situation, thus was always confused with all this mess.

            Like… just hit two keys, and your code looks like you want. Indeed, without that, I would have to rethink about this.

            ta!

          3. Indeed, I think this whole mess revolves around not using reformatting tools and not understanding that TISA is an option… but whatever.

      2. Certainly 🙂 I know I should be making more money 🙂
        Actually I only use vim for programming, none of this newfangled IDE stuff for me. In vim it’s trivial to :set expandtab which will accept tab as input but replace it with the appropriate amount of spaces. Combined with :set smarttab you don’t notice the difference with real tabs (besides that your source is larger, which in the early days was actually a concern…).

        1. Mario Rivera says:

          You can use vim editing inside a lot of IDEs nowadays. Best of both worlds? Give it a shot. Newfangled things sometimes are good.

  15. Perhaps programmers who use spaces also participate in satanic rituals

  16. I prefer spaces, but naturally one must adapt to the the coding style used in the project, so I am fine (begrudgingly) with tabs, but what really grinds my gears is when both are mixed – this causes such a horrendous mess…

  17. My IDE always offers to convert spaces to tabs… thus CRUELLY KEEPING MY SALARY DEPRESSED!

  18. Michael Beskin says:

    gofmt uses 8-char width tabs for indentation. Are the Golang devs making ~$20k more with spaces not using gofmt?

    1. gofmt uses tabs, your editor makes them 8-char width 🙂

      1. Michael Beskin says:

        gofmt even standardizes the width

        . . . of course you are free to change it in your editor to be whatever you want.

        1. Oh, interesting — it even understands TISA. That’s great!

  19. The very recent video “The Post JavaScript Apocolypse” on youtube features Douglas Crockford who says “If you can use one and do without the other, discard the other.”. We cannot do without spaces but we can do without tabs. This clear reasoning removes ambiguity and is a good practice to use this thought in code for all types of things that cause arguments but are not important. Its possible the slight nudge in one direction or the other may correlate with the small % of people that actually think this way where as it may only be a preference in the vast majority of cases as it is in mine.

    1. Sven Slootweg says:

      I’m sure it’s a nice-sounding aphorism, but from a language design standpoint that makes *no sense*. With the same reasoning you could eliminate lots of operators and formats from languages, making the remaining operators have more (ambiguous, context-dependent) meanings. This is obviously not a desirable thing.

      It’s no different with spaces vs. tabs — they have different semantic meaning, for different purposes. *Could* you use one to replace the other? Sure, but you’d lose the unambiguous semantic meaning, which is a bad thing.

      1. This is not a good example of “unimportant”. We would all do assembly language then by your reasoning.

        1. Sven Slootweg says:

          What are you talking about? This has absolutely nothing to do with “using low-level languages” (which I presume is what you’re referring to), it has to do with unambiguous language design. “Assembly language” doesn’t come into it.

          I feel like you’re trying to have an entirely different discussion, totally unrelated to the point I’m making.

          1. Contextually, Crockford was arguing about coding style, not about language design, specifically when it comes to tradeoffs of equal functionality that your team decides as a coding style. In that light, my assembly reference does relate to you taking an argument too far, for example if you said, we might as well only use assembly if we must reduce things to their basic functionality but instead, you used “language design” which is equally too far out of scope.

          2. Sven Slootweg says:

            An analogy is not an argument, it’s an illustration. At no point did you actually argue how my argument was being taking “too far”, and you still haven’t done that. If you disagree with my argument, fine, but then *address the argument on its own merits*, don’t just throw in a poor analogy.

          3. Try a sentiment analysis on your post history. You will find it enlightening.

          4. Sven Slootweg says:

            And now you’re attacking me personally, instead of addressing my argument. If you don’t have a counterargument, then it’s fine to just refrain from responding, you know.

          5. There’s no argument in the first place which was the point. It was about context which limits scope. However your sentiment averages toward negative which is unbiased if you use an AI. You are able to change that upward if you want to.

          6. I’m seeing a pattern here in your responses. You are always correct from your perspective coupled with negative sentiment. Hope that works out for you.

    2. You may have just converted me.

    3. Well we use tabs for something different than spaces, when we use it for indentation. By your argument we would all code with 3 symbols as those are the fewest symbols we would need to program.

      1. Taken out of context. Douglas was referring to unimportant arguments about code style. If you take it in that context, your argument seems reaching.

  20. Maybe being extravagant in your use of bytes reflects an attitude of plenty that becomes a self-fulfilling prophecy in life.

    1. Félix Gagnon-Grenier says:

      oh, so that’s what closing the line break html tag was all about…

    2. The attitude of plenty is rampant these days.

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

  21. I’m a 10x spaces engineer. Your codebase is going to have so many more spaces in it when I’m done with it. Certified spaces growth hacker.

    1. I take it you’re a certified Whitespace developer then?

      1. I only work with /[ ]+/g not /s+/g

      2. all that whitespace isn’t going to print itself chris.

  22. acommenter says:

    I think it’s funny that tabs people in the comments are saying “well it’s probably some other variable!”. The other confounding variables are exactly the point. No one actually believes that switching from tabs to spaces will gain you a nice raise. It’s the type of personality (or habits, or whatever) that lends itself to spaces that is more rewarded.

    1. That is exactly what I suspect

  23. Petar Donchev says:

    Some languages have universal convention for one or the other – for example Python for spaces and Go code for tabs. So Python programmers definitely earn more than Go programmers?

    1. but go you just use fmt…. who cares what you write go will fix it

    2. Except the last graph shows that for both Python and Go developers, spacers earn about 33% more than tabbers.

  24. I find this to be both hilarious and insightful. Thanks for sharing.

  25. Benjamin H says:

    Yeah, developers who use space over tabs probably do make more money. Because developers who use tabs get the job done faster, and as such, work less hours!

    They are ‘Whitespaces’, a useless character in most languages, and yet you waste eight key strokes on them, when you can do the same with one!

    1. Sven Slootweg says:

      Almost every modern editor supports soft-tabs; that is, by hitting the TAB key, you insert N space characters. “Eight keystrokes” is not realistic.

      1. Benjamin H says:

        Perhaps not eight, but unless N is equal to one, my point still stands.

        1. N is equal to one

          1. Benjamin H says:

            Ya, misunderstood!

          2. No: Sublime Text can obviously insert spaces when you press tab: https://www.sublimetext.com/docs/2/indentation.html

          3. Do you honestly think people actually hit the space multiple times? Dude.. Everyone just changes the TAB output to X spaces.

          4. Yeah I misunderstood

        2. No, it really doesn’t.

        3. Sven Slootweg says:

          N *is* equal to one when using soft-tabs. That’s the whole point…

        4. I press TAB once, the editor inserts ‘N’ spaces with N being the number of spaces needed to make the result visually the same as a hard tab. Try to grasp this concept, apparently it will make you earn more money if you do.

    2. Giorgio Polvara says:

      This is the problem with that “Silicon Valley” episode. Nobody is hitting the spacebar eight times, people just use tab but render it as spaces

      1. ive worked with developers who use space manually… it … is horrible

        1. Giorgio Polvara says:

          I don’t see why anyone would do that

          1. Neither did I until I saw Tyler’s answer above. I didn’t imagine anyone would have to sub-condition themselves to handle the situation…

    3. Tyler Hibbard says:

      People indenting by 8 characters instead of 4 are the real problem here, let’s be honest.

    4. Mike Barlow says:

      Try saying “Whitespaces” is a “useless character” when coding in Whitespace – https://en.wikipedia.org/wiki/Whitespace_(programming_language)

      1. Bryan Oakley says:

        or python.

    5. Bryan Oakley says:

      Nobody wastes eight keystrokes for indentation. Us space users use the tab key just like you guys. Every decent code editor will do the right thing and insert the appropriate amount of spaces and/or tabs.

  26. How are those using linebreaks :)?

  27. I’d love to see some error bars on your bar graph. 🙂

    1. Ryan Thompson says:

      With 12,000 respondents, the error bars are likely too small to be visible on this scale.

  28. Edwin Ramirez says:

    I’ve always been confused about something: What happens when I set my editor to output tabs as spaces?
    I’ve been using Sublime for years, recently jumped to Atom and VS Code; but in all I always configure my tabs to be 2 spaces.
    On what side am I? I prefer spaces for indentation. It’s more readable, less “empty space” on my screen. But I’m not a fan of smashing my space bar 2 – 6 times for each line.

    1. You’re basically using spaces. If I change the keyboard letter A to output Z it doesn’t mean I’m using A.

    2. Alfonso Pérez says:

      That’s spaces, I don’t think a lot of people do what you say ‘smash the keyboard repeated times’

    3. Inquisitor says:

      I think everyone does exactly that. I don’t know anyone that puts spaces in manually.

    4. Tyler Hibbard says:

      The only logical answer is that you are in the tabs group, because you are pressing the tab key to indent. Perhaps the survey’s next iteration should specify to respondents that “spaces” means “pressing the spacebar X number of times”, and we’ll see if this correlation stands.

      1. I’m pretty sure no professional programmer presses “space” repeatedly. The survey was asking after the textual representation, not the key you’re pressing.

        1. Tyler Hibbard says:

          Hi, professional programmer here. Who presses space repeatedly.

          1. Félix Gagnon-Grenier says:

            You may want to revisit that 😉

      2. Bryan Oakley says:

        “The only logical answer is that you are in the tabs group” – I completely disagree. The debate isn’t about what key you press to do indentation, it’s about what characters are in your source code.

        1. Félix Gagnon-Grenier says:

          finally… the only thing more baffling than tab users thinking space users mash the space key repeatedly, is tab users thinking tab is actually about the tab key, and not the tab character.

    5. Bryan Oakley says:

      If your source code has tabs in it, you’re a “tabs user”. If you use the tab _key_ but have spaces in your source code, you are a “space user”.

      The debate isn’t about which key you press to do indentation, it’s about what characters are actually in your source code.

  29. caitlynmayers says:

    I’ve configured my IDE to allow the tab key to use spaces. Prefer tab key for efficiency, but understand the spaces necessity. Does this data account for the ability to use the tab key to execute spaces? How would you categorize this group?

    We got into a heavy debate about this at work, to the point where I made team tabs and spaces shirts. Tabs has been printed twice, Spaces none, if that’s any indication.

    https://cottonbureau.com/products/team-tabs
    https://cottonbureau.com/products/team-spaces

    1. I imagine most developers in the “spaces” camp do this. I know nobody who favours hitting the space bar multiple times over hitting tab once. But this would certainly be an interesting hypothesis!

      1. Tyler Hibbard says:

        I am a dev who actually hits the spacebar 4 times (if my IDE doesn’t automatically indent for me when I hit enter to go to a new line). I avoid using tabs because it’s not much of a time saver and specifically because we are conditioned to expect “tab” to be “move to the next UI button/element/file” in any other computer context. I’d rather not have to hammer a sub-condition into my mind for “different tab behavior but only in this one IDE”.

        1. Bryan Oakley says:

          Why? Every modern IDE can be configured for the tab key to enter the proper number of spaces. I can’t imagine having (or choosing…) to type four spaces every time I wanted to indent something. Dude, get a better editor!

          1. His point is (if I understand correctly) that way the behaviour will be consistent even if, for whatever reason, he has to use an editor that doesn’t understand this — or even, I suppose, if you’re typing code in a text box on a web page where tab instead causes the focus to go to the next field..

        2. Except word processing and document layout, where we expect tab to be “move to the next tab stop/indentation level”. The tab=”indent” convention is both older and more widely known than tab=”next control”.

  30. I’m a tabs person, mostly because it’s simply the right choice. Firstly, the file size will be smaller. That has to be the preferred choice. Who would choose to have their files be larger? Secondly, it gives you total flexibility in terms of choosing how big a tab is in your editor. If you’re weird and prefer a tab to indent by 8, then that’s your choice. Those who have incredibly nested logic can use 1 or 2 characters. Personally I always choose 4. The thing is, you choose how you want to see it. If the file is using spaces, you don’t get any choice. The indentation will look the same always. If you want to ensure that people always see it the same, you simply specify in your coding standards that people should always set their indentation level in their editor to 4. I’d love to hear any real advantages to using spaces, other than the salary increase 😉

    1. Tyler Hibbard says:

      “I’d love to hear any real advantages to using spaces other than the advantage this entire blog post is about” 😉 Also good look specifying *your* coding standards to dictate that *other people* change their own settings to match your preference.

      1. The advantage of a tab is that it allows you to choose your visible indent size. However, varying indent size makes it functionally impossible to enforce column width. Therefore if you have a coding standard with a fixed width, spaces are the appropriate choice for justification.

        1. Why would you need to enforce a column width though? Alignment after indentation? If that’s the case then I guess the real reason there’s such a war over this is people don’t understand TISA.

          1. By column width, I meant the total document width. (I didn’t write clearly, sorry). If a document has a 100 column max width, and one person uses two space tabs, and another uses four space tabs, and another uses eight, and they all use a 100 character width, then when one person views the work done by another, then the formatting will look wrong.

            The 8-char equivalent indent will look short on the 2-char equivalent user’s screen, having randomly short line lengths. The 2-char equivalent user’s code will overflow the 100 line length limit on the 8-person view. Alignments (say, for simple ascii images) are going to be off too.

            It’s going to lead to a code base that just looks wrong and messy.

            I don’t think tab/spaces matters for your own code, but if you’re in an environment where many people edit the same code, then using spaces with a fixed indent makes it easier to keep the code clean looking.

          2. What you’re saying doesn’t really make sense to me unless you’re talking about in-line alignment; Tabs (actual tabs) are only for indentation, so the width of a tab doesn’t matter. You wouldn’t align the insides (and technically leading spacing, after indentation) of ASCII art with tabs.
            It wouldn’t “look wrong” anywhere. Now, yes, you can exceed a column limit but unless you set it to something insane line 10 or 20 that’s hardly an issue (unless you’re the type of person to be totally inflexible about that column limit, which will give you other issues anyway).

      2. Mike Barlow says:

        ummm it’s real easy to “dictate” that *other people* change their own settings to match your preference. It’s called using a static code analysis in your build process (I have our lint checker to check and error out if spaces are used in any code).
        You want to use spaces in your code? Great, but your code won’t pass the build queue if you do *wink*

        1. Tyler Hibbard says:

          This assumes that you’re the person in charge of setting and enforcing coding standards for your group, and also that you’re only talking about code environments where code is shared within a small group, which are two pretty big assumptions. It’s also a pretty douche thing to do if you block spaced code.

          1. Mike Barlow says:

            Well wouldn’t it also be a pretty douche thing to do to block tabs? And aren’t coding standards supposed to enforce a consistent style (see: https://www.smashingmagazine.com/2012/10/why-coding-style-matters/)?

            I prefer tabs (that’s just my world, but I can work with spaces if needed). But what happens when I’m walking through someone else’s code and they use spaces, but for some reason didn’t always use a 4 space indent. Their code could look messy and take longer to walk through. Or worse yet, consider the developer who doesn’t use indentation at ALL and try to walk through their code to figure out what’s going on (I’ve personally come across both style of coders, my boss falls into the latter group).
            Code Standards and Coding Style DOES matter, even if it’s only you working on the code.
            … stepping off my soapbox now

      3. Bryan Oakley says:

        The main advantage as I see it is that everyone on a project seems the same code. While it should be avoided, we sometimes like to line stuff up in columns, or align multiple lines of code or data so that it’s easy to read. These alignments simply don’t survive varying tab widths. Combined with the fact that you can’t see tabs, so “foobar” may appear as “foo bar” or “foo bar”.

        Perhaps the real debate is simply between people that see that as a problem, and people that don’t.

    2. ever heard of minification? It uses the same principle as the one you’re arguing for, which is who would want a bigger file size 🙂
      Got my tab key to insert 2 spaces on vim

    3. Ole Laursen says:

      No worries, one day you’ll understand why spaces work better when you’re working with other people, and then you’ll switch and be a better colleague, and ultimately earn more.

      If you want to speed up the process, read jwz’ rant. I don’t think reading it is enough, though, it’s a really deep issue.

      I still see indentation issues from time to time in other code, and every single time it’s caused by someone using tabs. Sometimes a previous version of myself.

      1. Well, for me the ultimate solution to the problem is `go fmt`. It solves the multi-programer problem without sacrificing any principles. I wish more programming languages would supply such tools (code formatting normalization).

      2. It seems to be more a case of “waaah this breaks my software” more than anything. TISA is the best solution.

      3. Hernan Silva says:

        I sincerely would like to know how spaces are better for working in a team, I’ve seen this as an argument several times but I can’t find why… I mean, how is it that you would not mess up with spaces and would with tabs? If all developers on your team are using tabs, how would spaces benefit the team or its members?

        1. Bryan Oakley says:

          The main reason is that you quite often can’t see tabs. If you type “foobarbaz”, it may appear as “foobar baz” or “foobar baz” or something in-between, depending on your tab setting. Thus, it can be impossible to distinguish between words separated with a tab and words separated with a single space. Though, I acknowledge that some modern editors will display a symbol for a tab, which solves that problem.

          There’s also the problem that, as programmers, we sometimes like to line stuff up. Due to the nature of code, lining things up with one tab setting may look awful in any other tab setting, thus making the code harder to read for some, easier for others. You can make the argument you should never attempt to neatly line up code, but there are sometimes good reasons to do so.

          Can you work around all these issues with tabs, or simply live with these edge cases? Yeah, probably. The argument for spaces is that these become non-problems that don’t need to be worked around. It’s One Less Thing to worry about.

          1. Most people I know who use tabs only use them at the beginning of the line. This allows a semantic “one level of indentation” that the reader can control how large it displays.

            I don’t recommend using tabs to align things, because then you are correct, it won’t work depending on the tab size. (TBH I don’t recommend aligning things at all but that’s an entirely different story)

          2. Yes. The correct answer is tabs for indentation, spaces for alignment, and alignment is generally to be discouraged.

            The problem with spaces for indentation has exactly the same foundation as people are complaining about for tab width: one developer wants to use 2 spaces per indent level, the next wants to use 4. With spaces this problem is worse than with tabs because you can’t correct for it properly with local settings. You end up with the first indent (from dev A’s revision #1) at column 2 and the second indent (from dev B’s revision #2) at column 6.

        2. Ole Laursen says:

          We can certainly agree that if everyone always uses tabs consistently and everyone always uses the same editor configured in the same way, then tabs will work fine, and even allow people to use different indentation widths.

          Now, the problem is that those two requirements don’t hold in practice E.g. you need to look at code made by others, and those other people need to edit your code. Once you have a mixture of tabs and spaces, the code will start looking weird for someone, not necessarily you.

          My favourite example is when you look at code written by tab fans who configure their tab width to say 4 spaces. It is often the case that the code isn’t actually consistentely formatted with tabs, so with a default 8 space tab that most editors will use (or view source in the browser for that matter), it looks garbled.

          I’m afraid it’s a real and annoying problem. I used to use tabs myself.

          I’m aware you probably won’t believe me until you’ve experienced it yourself.

          1. So your argument isn’t about spaces nor tabs, it’s about giving up and using spaces because then you don’t need to worry about it. I mean really, that argument could be applied anywhere where there is any sort of debate on how or what to use — package managers, specific packages, etc. … but you can standardize either way, and need to make sure people follow the standard, otherwise you’ll experience breakage no matter which debate it is.
            Or am I missing something?
            To be clear, I *have* experienced this, and not just in the tabs VS spaces scenario.

          2. Ole Laursen says:

            I’m sorry if my opening comment offended you, I was trying to be joking, but I apologize if it came across condescending.

            Now, to your question: The thing is, if everyone uses only spaces or only spaces and 8-space tabs, it mostly works everywhere because all editors and viewers understand spaces (well, HTML interpreters ignore them unless in pre tag, but…) and many viewers also handle 8-space tabs okayish.

            Now someone figured out that you can use tabs as a sort of system, just like when tabulating data. The benefit is it enables people to configure their favourite tab width. And some people do that, and THEN we have the problem because suddenly we have non-standard tabs so the file is going to look different to everyone else than the author and people with editors configured like the author. Worse, the code can end up being inconsistent, unnoticed, and then it can garble up completely for other people. The only way to fight that is to start being careful about the tabs.

            And right there is the point where the slight benefit of tabs just isn’t worth it compared to the downsides.

            You seem to think that you can standardize everyone to use tabs. You can’t. And as long as you can’t, you can’t have custom tab widths without causing trouble for other people, and if you’re going to use 8-space tabs, there really isn’t any benefit at all if you’re using an editor more advanced than notepad. And there are still downsides. My life was simpler when I decided jwz was right and I made my editor not insert 8-space tabs, navigation became much more intuitive.

            Now this is an argument, mostly against inserting non-standard spacing in text that other people may have to look at. 🙂 I don’t think my previous comment was an argument, really, I was just explaining what I’ve come to see.

          3. The fact that people don’t have the same indentation is irrelevant though, unless you’re using tabs *everywhere* on a line rather than sticking to Tabs for Indentation, Spaces for Alignment (TISA) which seems to be a distinction people would rather just throw out and simplify.

            Certainly, though, no matter where you stand on it if you’ve got people mixing it up, which you probably always will unless you employ what I’ve stated elsewhere makes the whole debate moot, it’s going to make a mess either way.

          4. Anyway, yeah, I wasn’t sure how much of that was you just being crude or joking, so..
            Unfortunately people don’t make much of an effort to make that clear either. 😉

    4. Larger file size? REALLY? Is that what keeps you up at night?

    5. until you work in a language in which indentation matters and you work as part of a team.

      For example, in yaml, you have to use spaces because people with 8 space tabs could be confused with those who use 2 tabs with 4 spaces each.

      If you colleagues use 2, 4, or 8 space tabs code will not be aligned for everybody. Only using spaces guarantees it. Readability trumps trying to save bytes.

      1. This isn’t true. You use tabs at the start of the line and everyone can use whatever tab size they prefer. That’s the whole point of tabs! They are useful to mean “one level of indentation” and every reader can decide how big they prefer one level of indentation to be.

      2. “Readability trumps trying to save bytes.”

        Especially with the ever-widening gap between how few bytes code requires vs how much bandwidth and storage is available.

      3. TennSeven says:

        Uh, no. If you use the tab *key* and it actually inserts 2, 4, or 8 space *characters* into the code, then you do’t really use tabs, you use spaces. However, if I use actual tab *characters* it doesn’t matter if my editor spaces tabbed content at 2, 4, or 8 spaces, when someone else on the team opens it, his or her editor will show it with his or her preferred amount of space. This is the beauty of tabs. I might like my code super-indented and so my tabs look huge, but someone else might prefer really small indents to take up less horizontal space, and that’s what he or she sees.

        Additionally, if someone else prefers spaces, he or she can just tell the editor “change every tab to X spaces” (X being whatever number of spaces he or she prefers) whereas if I use 4 spaces and someone else gets my code and prefers 2, they have to first figure out how many spaces I use for each level, and then run some kind of replace to get things to look how they want it, which is more of a pain.

    6. Tomasz Przybysz says:

      The main advantage of using spaces is that they always display the same way. I know that those who praise tabs use the same exact argument as a disadvantage (or rather the point that tab can be displayed according to ones preference) but this argument is invalid. There is plenty of places in which such a setting cannot be set. Code nowadays is being read end edited in many different ways, not only with an local instance of editor/IDE installed on a developer machine. Let’s take GitHub as example. GitHub has quite narrow, not configurable code view. Tab is displayed as 8 spaces. This means a lot of code is being ‘soft-wrapped’ and split between lines. Especially inconvenient for side-by-side view of a diff.

      1. Jimmy Jim says:

        GitHub can be configured with CSS. Change tab-size to whatever you want.

  31. You didn’t account for age of developer. Age is likely to track with salary. The reason spaces are encouraged when training coders has to do with printing on paper. So older developers will have a different habit then newer developers.

    1. Tyler Hibbard says:

      Readability concerns are valid on screen just as much as on print. I don’t think that is a factor, though age tracking with salary should be accounted for.

      1. yes but readability on a screen that can be resized at will and has in infinite line length ( and also adjust tab spacing automatically) is a very different consideration then readability on a printed page that has a fixed with of 80 characters before it wraps, will be printed in12 pt font and will treat all tabs as representing a specific amount of space and the amount differs on different printing devices etc. Readability is important on both it is just when you have a screen you can adjust at will and software that fixes the tabs so the line up automatically running , tabs aren’t a problem. They become more of a concern on printing devices especially ones that don’t support soft tabs as treat each tab as fixed amount of space.

    2. Interesting hypothesis. I wonder about age correlating with printing on paper; I’m in my twenties but I will sometimes print out code on a piece of paper to examine, just to get away from the monitor and jostle my brain into focusing more on it.

    3. Tim McClarren says:

      That is not why.

    4. Bryan Oakley says:

      I’ve been a developer since the 80’s. Never once did I think about the ramifications of printing when thinking about spaces or tabs.

      1. It was something driven into me when I was a military contractor in the ’00 because they needed to print documents for code for the customer.

    5. David Robinson says:

      We accounted for years of experience, in both the regression and the first chart.

      1. But not age of developer. There’s a distinction.

        1. David Robinson says:

          We didn’t ask about age in the 2017 survey, but we did in the 2015 survey (as well as asking about tabs/spaces and salary), and the effect on salary is the same. Data here: https://insights.stackoverflow.com/survey

          Nor can one find a tendency where developers with the same years of experience that used tabs tended to be younger

          1. Good to know, thanks.

      2. oh, good to know. I don’t see it mentioned in any of your charts or summary so it is hard to tell.

    6. The thing that’s difficult about this explanation is that level of experience tracks pretty consistently.

      In general, older employees do have a higher salary floor. However, developers with the same level of experience most likely trained for it around the same time, so they very likely learned the same habits. A 35-year-old with 5 years of experience probably started learning around the same time that a 25-year-old with the same experience did, so they’re more likely to learn the same kinds of habits. I mean it’s possible that some people set aside their development careers for a decade, but I doubt that is a large enough population to explain the results.

      If age was a primary factor in the pay gap, I would expect that at the very least, the older languages would stand out in the regression chart.

      1. why, just because I was originally trained in C++ and Modula II doesn’t mean I use them anymore. I’m currently working in C# doing MVC/razor web development. Might be harder to transition to an open source stack because no one has been willing to pay me to work in one, but I am familiar with several. To me it seems like blatant ageism to assume because someone has been in the industry for 20 years they favor or are currently using old languages.

        1. That was not my intent, I apologize. The way I interpreted the post/survey, respondents didn’t have to choose only their current languages, so it seemed natural to assume developers who started earlier would be over-represented in older languages. (To be fair, something like Assembly would probably be more like embedded systems programmers)

          Regardless though, we don’t have the age data to do anything more than guess at its effect on the results.

          1. David Robinson
            said they did include the age data, but I don’t see it in the charts or elsewhere. So it may already be a disproved hypothesis.

  32. iusenotabsorspacesanywhere

    1. minus Seven says:

      you
      should
      use
      new
      line
      instead
      its
      amazing
      .
      Writing
      this
      comment
      made
      me
      hate
      myself
      .

      1. Kyle Strand says:

        I had a coworker who did essentially this. He also had incredibly long (sometimes 80+ characters!!) names for everything (classes, methods, variables….)

        Here’s a made-up example (C++):

        ProcConnectionHandle
        ProductNameInstrumentSystem
        ::createNewProcConnection_maybe_fromProcConnectionPool(
        ProcConnectionPool& proc_connection_pool,
        ProcConnectionStatus proc_connection_status_initial,
        MyReadWriteMutexLock my_read_write_mutex_lock_for_proc_connection_pool,
        ProcConnectionId proc_connection_id,
        ProcConnectionAddressIpv4 proc_connection_address_ipv4,
        ProcConnectionPortNumber proc_connection_port_number)
        {
        ……

        1. Robin Munn says:

          Wow… You have my sympathy for having had to read that. That’s just awful.

  33. Tony Adams says:

    I just switched to spaces. Maybe I should ask for a raise.

  34. spaces 4 lyfe

  35. I hate 17.5% of pro programmers

    1. You can set your editor to automatically translate all tabs to spaces. You’ll be able to love programmers again, since you won’t even notice the ones using tabs—unless they tell you.

      1. Václav Haisman says:

        Sure he will notice. He will likely set his editor to expand tabs to wrong number of spaces, given how many possibilities there are, and all the code will look fugly.

  36. 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. 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. 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. How? Spaces cause problems when reusing code, . . . same argument can be applied if what you’re talking about is mixing them; Is that what you mean? Really, a good IDE will change spacestabs as applicable, and if that’s not what you mean I’d need a clarification.

          3. Paul Ishak says:

            Another thing is the size of tabs aren’t always consistant with dofferent fonts… a tab is really just four spaces when typed on paper… personally, for me, a programmer of over 40 years, tabs have always been ugly when coding. not to mention when you start using different character sets. igh it can be a real nightmare…

          4. That’s a terrible argument considering the point is for them to be variable in size, but then again code editors were never made to properly understand tabs. Besides, spaces are generally much more variable than tabs in different fonts, I mean considering you get the whole fixed versus variable width fonts into the argument . . .

            AFAIK #9 is #9 regardless of the character set, care to enlighten me on that one?

          5. Paul Ishak says:

            No i’ll just wait until you’ve gained enough experience to encounter some of the issues that are known to space users, and if you never do then good for you!

          6. I like how you gained at least 6 years of experience in 18 minutes lol “my 34 years” “for me, a programmer of over 40 years”

            I mean I agree with you, copy and paste of code (provided you wrote it, trust its author, or at least read it thoroughly) is a pretty normal thing to do. But still, maybe pick a year?

          7. Paul Ishak says:

            that was a typo lol im on my cell phone. good catch though!

          8. Btw. when you reuse code by copy and pasting you are doing something wrong.

          9. Paul Ishak says:

            What makes you think copying and pasting is wrong? I think it’s funny that as a professional programmer you would ever even say that. Aparrently you’ve never had a colleague email you a snippet, or reused code from other livraries where you only needed one function, or copied code from a template into a new file. I guess its your ___ years of experience as a programmer vs my 34 years.

          10. commenter says:

            Well, that statement was not meant to insult you. It is just that I can still remember my first programing professor telling us ‘everytime you copy and paste code you are doing something wrong’ and over the years there are few statements which I found so true. Yes, sometimes we have boilerplate code which we copy as a template, like a default HTML file. But everytime you copy code you risk that you have to fix a bug in that code in two places at a later time.

            So I found that advice very helpful.

          11. Paul Ishak says:

            Understandable, but I’m not here for programming 101… to insinuate that anyone who would copy and paste code under any circumstance is doing something wrong… is a bit misrepresenting of your own reasoning ability…

          12. 40YO senior dev chiming in here. Copy-pasting code is a trap, because you don’t learn anything. Do it consistently for 30 years and you end up like a bunch of other poor old sods I’ve met who stopped learning, and atrophied.

            Copy-pasting is not always bad, but copy-pasting from Stack Overflow day in and day out is a deadly, deadly trap.

            I can only ask you trust me on that. I’ve seen what it does to people over time.

          13. Paul Ishak says:

            I think I can respectfully disagree without having to break my reasons down to neutron science.

          14. Mario Rivera says:

            Why does copy pasting imply not undestanding the code?

            Moreover, in my experience, “xxx years senior” labels indicate bad programmers. Good programmers don’t need to use the word “senior”.

          15. Joshua Lamusga says:

            I copy and paste code all day along. It saves me hours of time. The alternatives are (A) spend way too much time reinventing the wheel, or (B) pointlessly retype it all out the exact same. Copy -> paste -> review. Every time.

          16. commenter says:

            How about using libraries? Or inheritance when you are using an OO language?

          17. Joshua Lamusga says:

            Then you acknowledge that copy-pasting the code won’t work if you don’t have the library and can’t reference/include it. If you’re inheriting from a non-existent class and can’t make use of a similar class in your code, you shouldn’t copy-paste. With great power comes great responsibility, or something like that.

          18. commenter says:

            Well, I am not sure if you get my point. I am not against code reuse. I say code reuse is great (because it saves a lot of time). I am against duplicating code. So if the code you need exists in a library, use that library. But please do not copy the code from the library, but instead load the library, so that you can easily update it if there comes a better version at a later time.

          19. Mario Rivera says:

            You’ve obviously never worked on real-life problems.

          20. Mario Rivera says:

            What about that?

          21. Paul Ishak says:

            Especially when your clients pay over $100 an hour… You don’t get the luxury of proving you’re a coding ace… Unless you don’t really care about your clients time and trust, and your ego means more to tou. I say copy and paste as much as humanly possible…

          22. Mario Rivera says:

            A foolish consistency is the hobgoblin of little minds.

          23. Mario Rivera says:

            Nothing wrong with reusing code by copy pasting.

          24. Félix Gagnon-Grenier says:

            You’re right, it appears a few confused poor sods do it! However, it’s *far* from the majority, and my point that most people that think otherwise are misguided stands.

            Likewise, don’t take my word for it.

          25. That’s also my point, though 🙂 There are *some* people who hammer the space bar, and there are *some* people who think that’s the alternative to using tabs, but that’s far from the majority — on either side.
            I think we are both agreeing on that.

      2. Paul Ishak says:

        Another thingI want to say for notepad++ users is heaven forbid you recieve a file from a colleague who uses tabs when everyone else in the office uses spaces… God that is always a pain in the ass… Same goes for programmers who leave encoding on ascii, but have utf8 characters in their code… definitly annoying.

        1. …and vice versa, so y’know.. we technically agree on that.
          As for encoding, yeah, that’s definitely an issue.

        2. Mario Rivera says:

          Replace leading space with tabs, or replace leading tabs with space. It’s one regular expression: any editor lets you do that. What is the problem?

    2. Bones Justice says:

      Oh my, can you imagine? I strongly prefer spaces, but I would rather use tabs than listen to colleagues whack away at their space bars all day. Hell, I’d rather use no indentation at all.

    3. Edwin Ramirez says:

      Like really? ANY code/text editore/IDE lets you set your tab key to any amount of spaces you want. I ident with spaces but I’m not stupid enough to smash my space bar 2-6 times for each new line. Come on guys and gals.

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

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

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

  40. 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. 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. 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. 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. There are three obvious hypotheses about the evolution of a technical practice when an older generation doesn’t agree with a younger generation.

      1) Dinosaur: the old way is going to die off when those dinosaurs go extinct
      2) Child: the young way is going to die off when those children grow up and go to war
      3) Idealist: the issue will be decided through humble give and take and rational tradeoff analyses

      I tried to frame this in terms of insult throwing.

      I hit the tab key and it makes spaces appear in Emacs. This is the only true way. /sarcasm

      See the links on this JWZ trackback.

      https://www.jwz.org/blog/2017/06/developers-who-use-spaces-make-more-money-than-those-who-use-tabs/

      Key quote: “My opinion is that the best way to solve the technical issues is to mandate that the ASCII #9 TAB character never appear in disk files: program your editor to expand TABs to an appropriate number of spaces before writing the lines to disk.”

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

    1. RagnarDanneskjöld says:

      I scrolled down to post this same xkcd : ))

    2. 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. 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. Fun joke. Not relevant here. The author was clear that correlation != causation. Several times.

  42. I’m a 32nd Degree Master Tabster

  43. 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. 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. lol explain this to my boss who is unapologetically a tabs man.

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

  44. The HTML in this clickbait is tabbed with tabs.

    1. 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. They actually mix tabs and spaces.

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

  46. minus Seven says:

    WHAT KIND OF CIRCLE JERK POST IS THIS…….
    I would have expected better from stackoverflow.
    There is no reason given in the article to explain why.
    Correlation is not equal to Causation.

    1. Scott Lavigne says:

      Did you even read the conclusion?

    2. 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. 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. It says Correlation is not Causation in the conclusion. This is an interesting and amusing article and that’s all.

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

  48. 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. the only language should be something worse…

        1. sheanmassey says:

          COBOL?

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

    2. It actually describes people who replied “Both” as being indistinguishable to just tabs.

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

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

    3. It’s referenced right there in the very first graph and paragraph. You really didn’t read, did you…

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

  49. opinionated and irrelevant. also incorrect findings.

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

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

  51. Sagar Tanur says:

    Tabs are good. I can’t agree with this post

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

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

  53. elastic tabstops ftw

    1. Kyle Strand says:

      If only, if only, if only….

  54. Dennis Hort says:

    Take THAT Richard Hendriks!

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

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

  57. 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. Ctrl+v -> tab -> outputs a tab character regardless of the above config in vim. TMYK

      2. sheanmassey says:

        Me too! 🙂

      3. Thankfully, vim’s default Makefile config unsets ‘expandtab’.

        1. Red Cricket says:

          cool! didn’t know that.

    2. Rörd Hinrichsen says:

      ITYM

      (set-default ‘indent-tabs-mode nil)

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

  59. Billy Hinners says:

    Maybe the title of this article should be “Developers who use spaces more likely to exaggerate salary claims”?

  60. Great! Meanwhile blocker bugs in the SO/SE sites are well and alive! Way to go!

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

      Hmmmmmmm?
      Hmmmmmmmmmmmmmmm?
      [trollface]

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

  62. Biggest bullshit I’ve ever read

    1. Kyle Strand says:

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

      1. If you insist, heretic. Stand still.

    2. Félix Gagnon-Grenier says:

      dude… calm down.

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

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

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

      Amazing.

      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. do you even read? medians differ

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

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

  66. It’s simple. Programmers get paid per character.

  67. 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. They disappear when its minified.

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

  68. 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. 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. And of course that was a typo….
        “People using SPACES work at larger companies and therefore make more money.”

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

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

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

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

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

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

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

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

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

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

  78. Bill the Lizard says:

    Clearly employers are paying developers by the byte.

    1. Félix Gagnon-Grenier says:

      Me own bytes go to eleven.

  79. Josue Ibarra says:

    I automated that promotion for those that are interested 😉
    https://gist.github.com/ibarrajo/74a03b135079ee23f3ae0250de11fe4c

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

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

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

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

      https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/#comment-3363700432

      1. … 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. I don’t think anyone who uses spaces over tabs types the spaces individually. The IDE does it automatically for you.

      1. 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. 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. 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. 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. 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. 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. [code]char *foo = (
            “In”
            “Don’tn”
            “Seen”
            “Yourn”
            “Problem”
            );[/code]

            If ever something inside a pair of parenthesis needs to be broken into multiple lines, just break everything instead. If you would need to break and there are no parenthesis yet, just add them.

          4. 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. Are you saying to tab/space to match the placement of the brace in the first line? In older styles, I could see that, but now that most are going to names that “self-document”, that’s too deep for tabbing.

            So we’re not talking across each other, my thinking is:

            Employee.Address.CreateNewAddress( city, state, zipcode,
                 streetaddressline1, streetaddressline2)

            If I understood what you were saying about matching the length of non-tab characters in the previous line, you’d run into problems with:

            Employee.Address.CreateNewAddress( city, state, zipcode,
                                                                            streetaddressline1,
                                                                            streetaddressline2)

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

          6. If you need to break one, then break all.

            Employee.Address.CreateNewAddress(
            t city, state, zipcode,
            t streetaddressline1,
            t streetaddressline2
            )

            Yes, that is two more lines, but the indentation is unambiguous. Also non of the lines is even remotely approaching the length limit.

            So much for my preferred style.

            For the other option, the additional indentation to match the parenthesis only with spaces. In front of the spaces all the tabs used on the parent line. So effectively:

            ttt Employee.Address.CreateNewAddress( city, state, zipcode,
            ttt ………………………………………………………streetaddressline1,
            ttt ………………………………………………………streetaddressline2)

            That fits the appearance which many of these “manual space artists” try to achieve, while still correctly behaving with different personal preferences on tab width.

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

  84. You’re missing a variable prob

    1. David Robinson says:

      Code and data are here, try it out! https://github.com/dgrtwo/tabs-spaces-post

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

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

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

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

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

    [1]: https://en.wikipedia.org/wiki/Data_dredging

    > p-value 10^-10, so this is **still a significant result** even under highly pessimistic assumptions. That’s actually very surprising: You did sloppy statistical analysis and still managed to get a “good” result.

    [2]: https://en.wikipedia.org/wiki/Bonferroni_correction

    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: http://arks.princeton.edu/ark:/88435/dsp01hd76s238c ). But I just said I hadn’t expected to find this result, not that this wasn’t the first thing I checked.

      As it happens, I was interested in writing a blog post on tabs and spaces, and after first measuring the percentage using tabs/spaces/both the first hypothesis I tested was the salary difference. (Wouldn’t you?)

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

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

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

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

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

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

  93. Its also directly correlating with shark attacks.

    1. Not even attacks – just correlates directly with sharks.

  94. Axel Heider says:

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

  95. Brett Davis says:

    WHAT IF PEOPLE WHO USE SPACES ARE PAID BY THE HOUR AND TAKE LONGER TO TYPE STUFF?

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

  96. “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. 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. You’re making a straw man argument… exactly the kind of logical fallacy a tabs programmers make all the time… 🙂

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

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

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

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

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

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

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

  103. Eihab Khan says:

    Richard Hendriks needs to see this!

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

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

  106. Rodrigo Carvalheira says:

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

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

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

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

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

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

  111. 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. I’m a perfectionist in code quality and I do use tabs

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

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

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

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

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

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

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

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

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

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

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