Wednesday, December 8, 2004

Tabs Are Evil

For about the 10,000th time today, I opened a file that looks something like this:

  static Crypto()
            // Set up the Rsa provider to use the machine key store. If you don't,
            // creating the provider will fail when you run under ASP.NET. 

  CspParameters cp = new CspParameters();
            cp.Flags = CspProviderFlags.UseMachineKeyStore;

      // TODO: verify that we can encrypt 5 bytes, just so we don't get a 
           // false positive that makes us think we failed because of block size
I highly doubt that the developer who wrote it would have put up with this randomly indented presentation, so why do I have to? The problem is that developers love to hit the tab key to line things up, which generally inserts a tab character. Of course, different people and different editors choose different widths to use to display a tab character. Worse, it's easy to mix using tabs and spaces to align your code. After all, it'll look lined up to you, but when I open it, I get the mess above.

So, run, don't walk, to your favorite development tool and set the equivalent of this VS.NET option:

This will cause VS.NET to insert n spaces (instead of a tab character) whenever you hit the tab key, where n is whatever value you put in the “Tab size” textbox. I don't particularly care what number you use (although 2 is clearly the choice of the most discerning developers) - the point is that as long as you don't use tabs to line up your code, it'll line up for both of us.

This has been a public service message brought to you by the Terminally Picky Developers Association for Readable Code.


  1. Ctrl-K F will fix whatever code you have highlighted. I use it all the time - some people I've worked with seem to think the opening brace goes on the same line as the function declaration...

  2. Oh, I'm well aware of ctrl-akf. But changes to formatting cause the file to show as modified, which is a pain. Worse, if you're using VS.NET with integrated source control (evil, but I'm forced to at one client), it'll cause a checkout.

  3. Plus, the equivalent for XML files in VS.NET (control-kd) absolutely sucks. The reformatting it does is often worse than the original, messed-up file, so it's not an option.

    And on top of that, I often open files in other tools.

  4. One could argue it's the spaces that are evil. ;) It's not the tab that's the problem per se, it's the mix of tabs and spaces. I've tended to stick with tabs in the past because a) it's easier to indent and unindent outside of the IDE, and b) it's the IDE default, which means other people are more likely to be using tabs.

    I believe in VS2005 they're changing the default to use spaces rather than tabs, though.

  5. I've read other "coding standards" that conform to what Kevin says, the problem is the mixing. I'm a tab fan myself (although it does cause some grief in SQL - the tabs always look different in Enterprise Manager versus the way they look in Query Analyzer... maybe I should convert religions?).

    The file change doesn't bother me so much, but I've not had the opportunity to work continously integrated yet, so that would probably change my opinion.

  6. I'm willing to grant that all tabs all the time would be as good as all spaces all the time...but the editor doesn't have a setting for "insert a tab for four spaces", so I'd have to concentrate pretty hard to make sure I never got a mix.

    Inserting spaces for tabs, on the other hand, is available in many tools. And, if you use two spaces, the only downside is having to hit backspace one extra time when deleting over one, as you can still use tab to insert a pair of spaces.

    But absolutely: it's the mix that's the real evil.

  7. I agree 100%. Another great tip: set the default view for ASPX pages to be "HTML Layout" instead of "Design Layout" due to magically disappearing event wireups and other "helpful" formatting that VS does for us. :-)

  8. I also find the VS.NET regex replace-in-files functionality to be very handy:

    find: "\t"

    replace: " "

    2 spaces. Amen. :)

  9. Regex: nice - I hadn't thought of that. Easier than ctrl-akf when working with lots of files.

  10. Craig Andera says that Tabs Are Evil and wants developers to indent with spaces instead. Now Craig is the last person I'd want to stoke a holy war with, but spaces are even more evil. If you use, say, 4

  11. Here's one. Not that it matters much. Using tabs will reduce your source size.


    Assuming indenting 2 spaces

    09 09 09 09


    20 20 20 20 20 20 20 20

    If 4 spaces,

    09 09 09 09


    20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20

    I like to use tabs with 4 spaces.

  12. Sorry, I can't buy that as a good argument at all. The same argument would say you should cut down on comments and try to keep all your source on the same line.

    Plus, amount of whitespace in you your source file has no impact on performance, time to compile, or anything meaningful, especially in an age of giant hard drives. You'd have to type *really* fast to fill 160GB with text.

    Oh, and if that weren't enough, I'll bet you $20 that both those versions compress to within 1% of size of each other. ;)

  13. Text based editors are evil. We should all be editing the parse tree directly. Then formatting would really just be a personal choice. No more arguments over tabs vs. spaces, where to put curly braces etc. It would all just work.

  14. The answer here is clearly that you should switch to VB.NET and let the text editor format the indentions for you! :-)

  15. Mark: while that's an interesting concept. Are there any tools that take this approach now with a general-purpose programming language?

    Paul: you won't get me to argue with you if you're saying that VB has a better *editor*. ;)

  16. You're missing the more important point here, 2 line comments should be encased in /* */ not two seperate instances of //


  17. Mark: I dimly recall seeing Wesner's post (or one like it) now. Of course, if we were all to switch to LISP, it would be a lot easier to write a parser. ;)

    Barry: :p

  18. Alright... my 2 cents:

    1. I agree with those that say the problem is in the mix and not in the tabs

    2. I don't understand why it takes a lot of concentration to stop pressing the space bar. Just stop doing it!

    3. The reason I like tabs is this: I can change the tab placement on the fly. So if I have some deeply indented code, I may switch to 2 (or even 1) space per tab. But for my code (small methods, little nesting), I'll keep it at 4, because to my eye it is more readable.

    4. I've used regex to go both ways. Works like a charm.

    5. Even better than VS's format is Resharper's format.

    That'll do for now.

  19. A few things:

    1. I'm primarily talking about reading code that others write - I believe I could be consistent, but I don't trust everyone else to be.

    2. I use many tools to work with source. Although VS.NET has support for changing indentation, others don't. Spaces are the only thing that works everywhere.

  20. I say use tabs for leading indents, and then use spaces for any alignment you want to perform afterward;

    int foo;

    string bar;

  21. Okay, so my text got reformatted upon posting. My point is that leading tabs work fine in all editors and you can easily adjust the tab width in many of them, and as long as you're using fixed width fonts any spaces later in the line of code will align perfectly regardless of the tab settings.

    I know people who prefer to code using proportional fonts (I hate this, personally, but I do know people who do it), and that makes alignment by anything other than tabs just plain painful.

  22. All of which are very reasonable suggestions...but all of them assume people have the discipline to follow some regimen other than "whichever key I happen to hit that looks right in my editor".

    If I were on your team, I'd adopt whatever policy you like, and I'd follow it. But IMO many people have just enough discipline to flip the IDE switch. And since I can't make them stop hitting the spacebar and/or tab keys, the next best thing is to make them stop inserting tabs.

    Just my two pence: as I've said before, hitting ctrl-akf is easy enough.

  23. Good post, we already do this and I agree 100%

  24. The mix is evil, but you're wrong - tabs, not spaces, are the way to go. With tabs each developer can get the indentation he/she wants - without changing the source code. Can't do that with spaces.

  25. As I've said several times now, I actually agree with that sentiment. The problem is that there's no way to enforce developers always entering tabs. They can (and therefore will) continue to hit the spacebar instead of using the tab key.

    If the tools supported automatically turning two (or three or four) consecutive spaces into tabs *as I typed*, then I'd happily use tabs. But they don't, so I'll always get a mix...unless I turn on "insert spaces for tabs". That's just the only option for automatically always getting consistent indenting right now.

    Believe me, I wish it worked the way you suggest. I have a client that has mandated four space tabs, and I hate it (I like two). But it's far better than a mishmash.

  26. FWIW, the CLR team internally disallows the use of tabs:

  27. I like tabs for the sole reason that if I used one use to enter it, I like to be able to use one key to navigate it. I do use spaces, but keying over them is a pain.

  28. I always put my code on one long line, separated by semicolons, to make sure my file maintains UNIX linebreaks compatibility ;-)

    I'm definately drawn to tabs, I always set it to 1 space width, so no problems with me...

    "You don't know the power of the tab side..."

  29. It's very simple guys. I like tabs and here's how I handle the tab issue with my favorite editor - vim:

    1. Open Joe Schmoe's file

    2. Determine Joe uses 4 spaces for a tab while I use 2.

    3. Do a ":set tabstop=4" in my vim editor

    4. All scattered lines line up like nazi soldiers - just the way they were supposed to be.


    Roumen Semov.

  30. Yeah I don't know why VIM even has 8 as the default - nobody ever wants that, do they? 4 is a much better standard and would result in programmers getting along much better if VIM (and every other editor) just shipped that way, I think.

  31. Here's a good case for spaces: