Tabs versus spaces: Spaces won

Why? Because since at least Visual Studio 2005, the default for tabs/spaces has been:

image

Insert spaces, not “Keep tabs”. If tabs were supposed to win, they would have won the default settings battle. If the default settings in Visual Studio aren’t “do tabs everywhere”, then you’re fighting some serious momentum against you.

I used to have “Keep tabs” on as my default, but this proved to be quite, quite annoying when working with teams or OSS development. If I get a pull request with spaces, I might re-format the document to have spaces. But then it becomes much harder to understand what has changed, since I have to fight with how well the diff tools deal with whitespace changes.

Even worse is the developer that re-formats documents they only look at, but don’t make any semantical changes to. I’ll see a commit with 5 changed files, but only one has actually changed.

I hit this with a pull request in AutoMapper, where the person submitting the pull request decided to replace all spaces with tabs, making it pretty hard to understand what changed without special whitespace switches.

Do you like tabs in Visual Studio? I do too! But I gave up the tabs versus spaces argument, and so should you.

Spaces won.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Rant. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://twitter.com/vkornov Victor Kornov

    Sorry, no.

  • http://twitter.com/moberg Peter Moberg

    Totally agree with you. Would prefer to use tabs, but spaces did win. 

  • Ramana R Kumar

    All we need is consistency.  On a similar vein…
    Wish one could do the same for CRLF. 

  • Chris Brandsma

    Trying to remember the last time I cared about this “issue”..  Sorry, still don’t care.

  • Waheed Sayed

    I was just thinking about this yesterday because of re-install of VS2010.
    I usually set few options as soon as I install a visual studio (Track active item in Solution Explorer & Line numbers & Keep Tabs!)
    I’m about to surrender & leave spaces (while I hate this decision) & I don’t consider it a Win.
    It’s just a MS rule and majority usually don’t care, even if it’s a vital issue, This is why I love Alt.Net.
    Remeber that Unit Testing took a long while to be in main stream of MS tools, and also a respectable ORM tool instead of DataSets & Stored Procedures!
    Spaces or Tabs issue was trivial to be considered in Alt.Net though I remember I read an advice that seconds the using of Tabs & I believe this’s the right thing.
    At the end, either to use spaces to make format consistent with other memebers or we’ll keep touching & reformating files without any real change!

  • Chris Tavares

    The argument I always heard in favor of tabs was “then everyone can choose the indentation they want”. But in practice, I’ve never seen it actually work out that way. If you code with three space tabs, it’s 95% probable that your code formatting only looks right with tabs set at 3 spaces, and on my screen with 5 space tabs it’s going to look like crap.

    Spaces won – real consistency is simply easier to work with.

    • Anonymous

       That sounds like a good argument for using tables for layout, too!

  • Anonymous

    I’m using spaces as default fo my all projects. And if OSS project uses tabs (NH for example), then I’m using git pre-commit filter to convert all spaces into tabs (
    http://stackoverflow.com/questions/2316677/can-git-automatically-switch-between-spaces-and-tabs ). Also github has an option to show changeset with ignored whitespace changes by adding `?w=1` to the url (
    https://github.com/blog/967-github-secrets ).

  • Pingback: The Morning Brew - Chris Alcock » The Morning Brew #1060

  • http://realfiction.net Frank Quednau

    The thing is, though, that there is a technical solution to it. Upon opening a solution the first time, the code-base should be parsed and where a majority of files show a certain setting with regard to spaces/tabs/indent space, those settings are used for editing the given code base.

  • MrDustpan

    I hate spaces, not ready to give up my tabs.  Sounds like our diff tools need to be smarter.

  • James Manning

    I’ve been on both sides during my career, but over the last 5-10 years have been in the ‘spaces’ camp (no, not Space Camp!) due to face-to-face code reviews and tools.

    During face-to-face code reviews (sitting at the person’s desk), if we’re both using tabs but they’re using something different for indentation per tab (I use 4, they use 2 or 8 or 3 or anything other than 4), then I find myself too distracted by the formatting.  The main point of a code review I’m doing is to *read* the code and mentally parse it out.  A formatting change like that makes my job harder for no real gain.  It makes me take more time to do the same job and makes it less likely I catch any issues.  The goal of good code is (or should be) to be easy to *read*, but I’ve found that insisting on tabs (in a team) means you’re placing the emphasis on being easier to *write* instead.

    The ‘tools’ issue is that I often don’t use just one tool for looking at the source (or diffs) to code, and with tabs you have to deal with getting them all set up with the same tab stops (assuming they even support changing it).  VS, Notepad++, KDiff3, ‘git diff’ output, etc. - ***if you use spaces, all tools will show the indentation the same, no matter what***.  If you use tabs, then out-of-the-box there are tools that won’t show it the same way as others, since many tools don’t show tabs as indenting 4 spaces (and that’s assuming you’re in the ‘tabwidth = 4′ camp – if you use a different value, your headache goes up quite a bit).

    A final thought: I’ve found that working in tab-based code, I sometimes think “I wish this was using spaces instead so it looked right in X”, but I can’t say that I’ve found myself wishing for space-based code to use tabs instead for any particular reason (although admittedly that is likely due to being in the tabwidth=4 camp).

    This kind of decision is where everyone needs to remember back to (or take) Econ 101.

    The 2 things to consider are marginal benefit and marginal cost.  And when it comes to tabs-vs-spaces, the marginal benefit of tabs over spaces are outweighed (at least IMHO/IME) by their marginal cost.

    Jimmy: can we expect K&R vs. BSD bracing styles to be the next post? :)

    • Anonymous

      lol not even TOUCHING that one.

      What’s funny is that the internal MS standard differs from the VS default. Go figure!

      • http://ianobermiller.com/ Ian

        This isn’t really true. First, code style is mainly a team-by-team, or org-by-org setting, so blanket statements about internal Microsoft practices are rarely true. Second, many teams use the default StyleCop rules and the default VS settings, which enforce spaces over tabs.

        FYI: I currently work in MSR, and previously worked in OSD AdCenter.

  • Anonymous

    Actually, I think choice won.

    Once a team standardizes on either, there really is no issue.

    • Anonymous

      I thought so too, until I floated around teams, and it became a complete mess. For a stable team and codebase, it’s *possible*, but otherwise, I do OSS, and it’s a pain to keep switching back and forth.

  • Jason Christian

    Sounds like the real issue is your diff tools don’t handle whitespace differences well.  Solve that problem and the tab/spaces argument goes away (personally I prefer tabs)

  • Greg MacLellan

    I agree that spaces has effectively ”won” (at least in the .NET world), but in reality it’s largely irrelevant. I used to use tabs, but switched to spaces for a couple reasons. Every editor I’ve used for the past many years has auto-indent and block indent/un-indent. 

    The other thing that absolutely drives me crazy with tabs is when people split a function call onto a second line, and try to vertically line up the arguments. Regardless of code indent as tabs/spaces, this should ALWAYS be spaces, but very few tab-using users bother to do this. Instead, they use tabs followed by a spaces or two to get it to align correctly, and then inevitably when you open it in an editor that has a different tab setting, it just looks like a big mess of code written by someone that doesn’t indent correctly at all.

  • James Curran

    Tabs all the way.

    Alignment using spaces is just wrong.   Alignment is the entire reason the tab key was invented.

    I prefer using a proportional spaced font in VS (try it !),  which pretty much requires the use of tabs for alignment.

    • Anonymous

      I agree, tabs all the way!

      Too bad it’s not the default in Visual Studio, making my preference moot :(

    • http://twitter.com/cpmcgrath Chris McGrath

       Indentation with tabs may work but alignment with tabs definitely does NOT work.
      Say you have
      FirstName = “Foo”;
      MiddleName = “Bar”;
      Surname = “Phoo”;

      and you want to align your equals signs. If you align using spaces all your equals will always line up, while if you use tabs, if somebody else opens the file and their tabs are smaller or bigger there is no guarantee they will line up.

      As for the proportional spaced font, there’s a reason fixed width has always been the standard.

      • Anonymous

        Tabs will only align from the start of a line.  If you want to align in the middle or with the middle of text above or below, you have to use spaces.

        • http://www.facebook.com/joequincy Jon Peterson

          That’s because that area between the start of the line and the code on that line is referred to as “indentation”, which is what tabs are… and anything beyond that becomes “alignment”, which is (shockingly enough) a completely different thing. Spaces have the latter covered nicely.

          In my experience, 90% or better of the whitespace to the left of actual code in any file tends to be indentation, and for that reason, I consider myself a “Tab” coder (since I use them most). But neither excludes the other, and anyone who actually gives a damn about the appearance of their code should do a little bit of reading on the definitions of “indentation” and “alignment”, and get busy coding legibly instead of getting huffy about which method another coder used, or doing a quick Find/Replace All and commit.

          • Anonymous

            The problem is, not all of the “start of a line” is indentation.  Part of that can also be “alignment”.  e.g. if I tab some code over from the right to indent it to the appropriate level, that line may also be a continuation from the previous line, at which point I may also be adding spaces after the tabs to align it in some way with the line before.  For example, I may space it over to align with a parenthesis.  It’s little mistakes like that that can lead people down the all-spaces route.  search/replace for spaces to tabs fails because it replaces alignment spaces with indenting tabs.

            But, +1 for putting emphasis the code rather than making sure everything is either tabs or spaces.

          • Jon Peterson

            I don’t know why Disqus fails so hard at notifying me of responses but…

            That’s what I meant. If a bit of code is a continuation of a previous line, I tab over to the start of that line (usually, my editor just clones the tabs from before) and then space out any necessary alignment from there.

            I consider a line of code to start at its natural* indentation point, not a cosmetic alignment point (however necessary it may be for readability).

            *whichever indentation style is required by your personal or company code cleanliness police.

      • offler

        bullshit.. just use another font, the width of the spaces is in most cases not equals to the width of a character. (only in some very special fonts…)

    • TRL

      Tabs were invented long before computers, and served a very different purpose than they do now. In the old days of manual typewriters one would use use tabstops to align text in columns, a concept rendered obsolete by word processors. The tab key would insert enough spaces to move the carriage from it was to the next tabstop. Yes, spaces: if the carriage was on on column 41 and the next tabstop was on column 50, pressing tab would move the carriage 9 spaces to column 50; but if you then hit the backspace, the carriage would move to 49, not 41 because the tab key inserted actual spaces, not ‘white space’. Tabstops were useful when one could set them arbitrarily across the page. Forcing tabstops to be at fixed intervals based on a global setting of the device has rendered them virtually useless.

      It should be obvious that mixing tabs and spaces is a tricky business, for example when you have a long function name and want to align the parameters in a column, one parameter per line. To do it with tabs requires that on each line with a parameter one must tab to the start of the function name and use spaces to move to the column of parameters. Tab uses, who are proud of the fact that they are too lazy to twiddle their thumbs, invariably tab all the way just short of the parameter column and fill in the rest of the way with a few spaces. The result is crap for anyone with different a tab setting. When one mentions this to a tab user they mumble yes, there are situations where you must use spaces for alignment, and then nervously try to change the subject. Put two tab users with different tabs settings in the same file any you quickly get the zig-zag code that tab users treat as the cost of doing business and drives space users insane.

      By setting insert spaces for tabs, you get a behaviour that most emulates what tabs were actually designed for and automatically results in a document that looks exactly the way the author intended it to everybody all the time. Less than diligent tab users will, on the other hand, quickly render a document incomprehensible to everybody all the time regardless of their tab setting.

  • Craig

    Rubbish: tabs have won: not seen spaces used in the last 10 years in any of the places I’ve worked (and not much in over 20 years) and I always make tabs the standard for the team.

    • Br. Bill

      A) It must be nice to always be the boss.
      B) I’ve worked for over a dozen companies in 3 states over the last 25 years and all of them used spaces as standard, except where req’d (makefiles, etc.).

      • Batdude

        The places I have worked in the past 22 years have all used spaces. So Craigs comment is pointless. This debate will rage on forever. Personally only spaces make sense to me.

  • http://twitter.com/Encosia Dave Ward

    I propose this post be renamed: Jimmy wants more pageviews.

  • Smithers

    Yeah, I lost this battle too :-(

  • Anonymous

    Tabs aren’t practical in reality because every editor has a slightly different interpretation of them. Too much effort – just use spaces instead and know your code will look good everywhere.

    • Tim Sygitowicz

      Look good to whom? With tabs, I decide how the code looks to me by setting the the number of spaces the tab represents in my editor. Then when you look at my code, it will look the way you want it to according to the settings in your editor. THEN it will look good to everyone. Who cares when your code ‘looks good’ to you when you’re not the one looking at it (i.e Who are you to dictate to me what ‘looks good’?). 
      I agree that Spaces my have won, but tabs are more versatile, and therefore better in my view.

      • Br. Bill

        “Then when you look at my code, it will look the way you want it according to the settings in your editor.”I can’t figure out how any experienced code writer would think this is true. When code is displayed using tab sizes other than the original author’s, the result is funky misformatted text, especially if commands use next-line continuation with lined-up arguments. Then it certainly WON’T look good to everyone.Unless everyone on your team/project agrees to never use such line continuation and to never use tabs anywhere but for indentation as well, your argument just doesn’t hold up.

        • Fabio

           What you said makes no sense, I also use tabs and everything is indented and lined up. If you choose your tab size of 2 instead of 4 like I do, then everything will shift left at the same proportion and it will look the same way, just another proportion.

          • Br. Bill

            This is absolutely not true. See my example later on this page and try changing the tab size to 4, 3, 2, or 6. See how that works out for you.

        • Anonymous

          This has been my experience as well. I can’t think of anything worse than spending ages fiddling to get all your tabs lining up just right in VS/Textmate/emacs/notepad++/etc. And then try to pasting your code into Outlook or an HTML blog post or StackOverflow comment and you have to fix all the tabs again!
          Spaces work out of the box everywhere without needing to play with IDE settings. And every editor I’ve used in the past few years lets you hit TAB (to get 3-4 spaces) so they’re just as convenient to use.  In my opinion… TABs lost this war ages ago

        • Anonymous

          You’re assuming that advocates of tabs have some strange aversion to using spaces. Which is totally incorrect.

          Of course tabs won’t line up with text if you change the tab size. Tabs should *never* be used to line up text; spaces should.

          In the ideal world, where programmers are considerate and not arrogant dolts, tabs should would used for indentation. That way another programmer can come along and set an indentation width that is comfortable for them (and their display). If you’re the kind of person who then likes to line things up, you should pad out from the indentation level using spaces.

          Now, using tabs and spaces is the ideal solution. But in the real world programmers are lazy, arrogant and inconsiderate. As such spaces definitely seem to have won out, which is quite unfortunate.

          However, now that VCS is common-place (and you’d be a fool to develop without it) perhaps we’ll see a reemergence of considerate programming practices. By omitting whitespace altogether from VCS repos, we can allow formatting rules to present code in a way that is comfortable for each developer. Unfortunately for that to happen we need IDEs that are actually capable of properly formatting code to become commonplace.

  • Eddie

    Love tabs, hate spaces. I think almost purely in terms of indentation / grouping of elements though, NOT absolute alignment. To my eye, if items that are related are indented the same amount, it doesn’t really bother me HOW BIG that indentation is (tho I prefer 4 spaces). All the aligning of field declarations and initializers just feel like a lost cause regardless of which you prefer. If I want that, I’ll use the IDE’s code formatting settings and let it reformat as needed – so at that point I don’t care. The thing I hate with spaces is in almost every file I see that uses them, there are lines that are “off by one” and they invariably look WORSE than something that uses tabs but with a different width set.

    Interestingly, I work with Java mostly now, but on the .NET teams I have worked on in the past the first thing we told any new dev was turn on tabs!

  • Anonymous

    I’m enjoying the love tabs are getting :) .  Seriously though, I think this is more a callout to get better “ignore whitespace” in diffs :)

  • Anonymous

    I’m convinced SCC systems should be white-space agnostic.  They shouldn’t store extra whitespace, and when you fetch, it knows your preferences and simply fills the whitespace with your preference.  I’m an idealist :)

  • Br. Bill

    Try this perl code with different tab settings. Guarantee you’re not going to get properly aligned code unless everyone’s tabs are the same.


    # tab setting = 5 for illustrative purposes (so that "{tab}" depicts the actual size of a tab)
    # opening quotes should line up. In lines 2 and 3, there are 3 spaces btw tabs and quote.
    # opening and closing parens should line up.

    {tab}@string_array = ( "this is a string",
    {tab}{tab}{tab}{tab}   "this is another string",
    {tab}{tab}{tab}{tab}   "this is a third string"
    {tab}{tab}{tab}{tab} );

    Note: You’re only making my point for me if you make a stink about my preferred layout of array declaration.

    • http://www.facebook.com/joequincy Jon Peterson

      I find this argument somewhat pedantic. Tabs are used to align blocks for readability. If you want to align something like your example properly across various editors, you’d mix in spaces for that purpose. Something like:

      {tab}@string_array = ( "this is a string",
      {tab}                  "this is another string",
      {tab}                  "this is a third string"
      {tab}                );

      This is because Tabs are not used to represent spaces; they’re indentation. Don’t confuse alignment to be the same thing.

      • Fabio

         I agree with you here Jon.

      • Tim

        Few people (myself included) are prepared to keep tapping away at the space bar to align with spaces like that. It takes time and it’s annoying with a large spaced alignment. You can hold down the space bar but then it shoots way off too far. Hitting the tab key a few times and then space to align is quicker but wrong if it’s set to add tabs. If it adds spaces for tabs then all is fine.
        That said, a good editor will just align under properly when you hit return and insert appropriate tabs or spaces depending on your settings.

        Generally I have no issue other than being consistent with whatever other developers use.

    • offler

      Bit old, but the argument is wrong. Spaces won’t align anything, except you have the same font in every environment.

      {tab}test = ( {tab}”a string”,
      {tab}{tab}{tab}{tab}”another one”,

      will most likely align “a string” with “another one”

      With spaces and different fonts (we had visual impaled people with very special fonts at former job) averything will look messed up.

      Worst case: If everyone configured their editor to use different numbers of spaces instead of tabs the code becomes directly a mess

  • Ralph Little

    Eclipse has a nice Tab/space mixture setting. Indentation is done using tabs and alignment is done using spaces. So when you you start a new statement on the next line, the editor uses tabs. Any alignment (e.g. function arguments in a column uses tabs to the primary indent, then spaces for the alignment. Gives you the best of both worlds. You can set the indentation as you like it, but the code still looks right.

  • Redsall

    I spent about 2 seconds making this decision years ago.  4 spaces (for indent and tab replacement) sufficiently separated column-ness and indent to the eye (vs. 2 or 3 spaces per indent level), and it looked good enough/worked.  So I simply accepted 4 spaces, and then immediately moved on to more important things in life; delivering valuable code.  Does anyone really sit there, and fuss over 2 vs. 3 vs. 4 vs. 5 vs. 6 ?  Good-grief !

  • Redsall

    Perhaps the Tab lovers are still using 64KB machines (yes, 64KiloBytes of RAM), and want to not use so much ASCII count in memory with 1 space = 1 Byte !?  :-)

  • http://twitter.com/jeff_vee Jeff Vera

    Giving up because of a default in a product is the definition of lame. Fight the good fight. 

  • Thomas

    The appeal of tabs is that they add some structure to plain text, but if you really wanted structure you would not be coding in plain text anyway. Since virtually every programming language is still coded in plain text, you might as well stick with spaces rather than trying to hack some structure into the code by using tabs.

  • DaveK

    I’ve been working in some different companies with differnt tools and different program languages and all I can say: It differs…it’s depending on your infrastructure, the coding language and in fact the way how your company works.
    I can work with tabs and spaces, but I totally prefer tabs since they are easy to use and more flexible than spaces. As long as there are some rules about that, it’s nice to have tabs.
    And the big positive point about tabs is: If you have some coding beginners in your company, they tend “not to see” some space missings. That means that sometimes you have to review code and recognize that the spacings aren’t correct, because the newbies just don’t see the failures (because they aren’t used to…). Of course, now you’d say that “if they are new in coding, they need to learn how to do it right from the start of their carreer”, but I say, we don’t live in stone ages anymore, we have tools for formatting and with tabs, most of them just know perfectly how to handle. Again, I must say it differs from environment to environment, but overall I’d say, tabs totally win.

  • Evan

    I’m in the tab camp as well. But, more importantly, I think the failure was where the settings are stored. Spaces versus tabs should be in the solution file and the preferred tab size should be stored in the registry or user data. That’s the real reason spaces won, not just that the default is spaces. If you could decide by solution, then, you’d really have the freedom to decide.

  • Renaud

    “Why? Because since at least Visual Studio 2005…”

    Since when has a Microsoft product become the Holy Bible?

    Tabs are far better than spaces: they are flexible, lightweight, and allow people freedom where spaces only impose everyone some groundless dictatorship rules.

    • jbogard

      I agree, I like tabs better than spaces. Unfortunately, I can’t specify this setting on a repository level. So, default wins.