Why Tabs Are Better Than Spaces

Let me first say that, as far as I'm concerned, this whole debate is scoped to languages where exact indentation is only a formatting aspect of which the compiler/processor is largely oblivious (the vast majority of languages). I know there are some languages out there where the exact horizontal placement of a line in relation to another carries semantic significance, but for all practical intents and purposes (especially within the context of the Orchard CMS codebase) let's leave those esoteric aspects aside.

With that out of the way, I think perhaps the best way to express my view on this topic is by addressing in turn the two common arguments I hear from spacemen (my term-of-endearment for developers who believe spaces are a better indentation choice).

Spaceman argument #1
"Spaces make you view the code as the author intended it."

The argument here being that if another developer views the code file with a different tab size setting, the code will not look exactly identical on her screen as it did on mine when I wrote it. The basic premise for this argument is silly to begin with. A code author does not (or at least should not) indend to impose her personal viewing preferences on anybody else. Encouraging or enabling her to do so is not a good thing.

If you want to force other developers to view your code exactly as you wrote it, you should create a PDF. :)

Let me elaborate a bit on why.

There is a good reason why we use text files to store source code, and why we like to use flexible and capable editors (like the one in Visual Studio) to work with source code: we all have personal preferences in how we want source code to be displayed. Some source code viewing preferences that most of us appreciate include:

  • Background color
  • Syntax highlighting colors
  • Font and font size
  • Word wrapping
  • Zoom

Sometimes these choices are based on habit or personal preference. Sometimes they are based on context or circumstance such as screen size, lighting conditions, etc. Sometimes they are based on disabilities such as vision impairments. And sometimes they depend on what kind of viewing I'm doing (e.g. am I comparing two files side-by-side or am I getting oriented in a huge new codebase?)

But these choices all have one thing in common: they change how the code is displayed. And that's a good thing! As far as I know, most developers appreciate these abilities to tailor the viewing experience to their liking. I have yet to hear even spacemen argue that any of these aspects should be preserved "as the author intended the code to be viewed".

Indentation size is no different: it really is purely a viewing concern and as such should be up each individual user to customize. It is every bit as much subject to the same matters of personal taste, context, circumstance and possible impairments as any other visual preference.

So why do so many developers think of indentation size differently? Well, I think the spacemen who make this argument might fail to recognize the difference between indentation level and indentation size. Indentation level is structurally relevant, it communicates something about the code and should definitely be considered part of the code and how the author intended it, and editors should represent it with full fidelity - no objection there. But indentation size (i.e. how many pixels wide do I want one indentation level to be on my screen) is not. That's a matter of visual preference. It doesn't matter to the structural representation of the code whether indentation levels are 2 characters wide or 4 characters wide. The visual structure remains the same, it just becomes more or less pronounced visually depending on my setting.

Spaceman argument #2
"OK but indentation isn't always structural, sometimes it's used to align things!"

What spacemen mean by this argument is that they have acquired the unfortunate habit of writing code like this:


Here's the thing though: using indentation this way will give you grief and extra work even if you use spaces to do it. You want to rename the method SomeNiceMethod to MyMethod? All right, go ahead. You will end up with this:


And now you'll have to go and manually fix up your indentation. The same goes for method declarations, lambdas, or anything else where you start an artificial indentation level on an arbitrary anchor point of a previous line. On any teams or projects where I have any influence over this, I ask people to not use this type of indentation, i.e. do not base the indentation of a line on any other anchor point of a preceding line than the *start* of that preceding line, because all other anchor points are moving targets.

Instead, I encourage people to use this style:


And I want to reiterate: the reason for this principle applies regardless of whether you use tabs or spaces. And if you follow this principle, then spaceman argument #2 ceases to exist.

So there, I said it. Once and for all. :) It's out there. I'm not a spaceman, and these are my reasons.

Having said all this, I should point out that I recently proposed formalizing on a set of formatting guidelines for the Orchard CMS codebase, and part of my suggestion is to use spaces (*gasp*) because it's what's used in most of the code, and I know most of the people working on the code prefer it. Which brings me to my closing point: the most important thing for any code base is consistency, so whether your team or project prefer spaces or tabs for indentation is of little importance compared to the importance of making a choice and applying it consistently.


  • ... Posted by Bertrand Le Roy Posted 01/23/2016 12:28 AM

    While I could kinda unenthusiastically agree on #1, if I had ever seen anyone seriously changing the default tab setting in their IDE other than to make a point, your arguments against #2 are plainly disingenuous. There are plenty of other cases where this applies, not only in C#, but even more in other languages (Go comes to mind), and tooling like R# will make the refactorings you invoke completely effortless: rename the method, and the formatting is modified along. You didn't give any arguments for using that remnant of teletype machines, only reasons why you think a couple of reasons to prefer spaces don't apply to you ;) One argument you didn't address is that in the end, spaces are just weird: visually indistinguishable from a space, they are the only semantically used characters in a monospace font that have a different width than everything else. Not only that, they have /variable/ width depending on where they are. As for "I think the spacemen who make this argument might fail to recognize the difference between indentation level and indentation size", oh cooome on, you're just trying to be offensive. Dick. :D At least we agree that what's important is to apply whatever choice we make consistently.

    -- A fellow pig

  • ... Posted by Bertrand Le Roy Posted 01/23/2016 12:29 AM

    Tabs! I meant Tabs! Tabs are just weird :D Argh!

  • ... Posted by Steve Posted 01/23/2016 08:34 AM

    So if spaces are to be used then is it 2 or 4 spaces? You don't have this debate with tabs!

  • ... Posted by Daniel Rosenberg Posted 01/23/2016 12:11 PM (Author)

    Bertrand: I could have bet money on you being the first one to chime in... :) I was both hoping for and expecting it.

    I tried to express the pros of tabs implicitly while refuting the alleged cons - sorry if it was too subtle. ;) But the pro is of course that I as a developer am free to choose how to view the indentation according to my preferences or situation. And while I do agree that many developers never change it, it is actually not merely fiction. I work on a team where some people prefer a tighter indentation of 2-3 characters, while others prefer 4. Using tabs lets us all be as comfortable and productive as we possibly can. As Steve mentions above, we are spared from that debate.

    Sticking to C# for the sake of brevity, can you provide a few other examples where you think it produces nice readable code to base indentation on an arbitrary anchor point of a preceding line? I can think of a whole bunch, and all of them are IMHO hideous and better written by starting a new line. Who knows, you might find one that I find it hard to refuse, however unlikely. :)

    As to the argument of "tabs are simply weird in a monospace world" I did see you mention this before and the reason I didn't bring it up here is that I simply don't understand how it's even an argument, one way or the other. It sounds so contrived - what possible practical implication does it have? Besides, we should keep in mind that tabs in text editors are not like tabs in word processors: they are expressed in multiples of the monospace width, i.e. in number of characters, not as millimiters or inches or pixels.

    And btw, don't think for a second that your Freudian slip wasn't duly noted, and won't be preserved here for future generations to enjoy... :D

  • ... Posted by Ludovic Posted 01/24/2016 04:16 PM [http://ludovic.chabant.com]

    Woooo, is this a pig convention? I'm in :)

    Daniel, I find your (counter)argument #2 pretty valid, but yes, I know a lot of programmers who just like to align things in various ways (not just method arguments on following lines, but also other situations).

    About your argument #1, however, it sounds a bit contrived to me. Your list of "things you're supposed to customize" is good, but notice how it doesn't include any white-space-related things? Programmers will also disagree widely on whether to add spaces around operators, spaces between the "if" and the opening parenthesis, etc. They will also disagree on where to put opening braces (at the end of the line, or by themselves on the next line), and other things that you could also put (for most programming languages) in the "purely cosmetic, I should be able to change it" category. If anything, you could think that IDEs like Visual Studio who include "code beautifiers" should actually support "non destructive code beautifying"!? Where, based on your personal tastes, it would add/remove spaces, move brackets around, etc... but just for you, while keeping the version on disk consistent with the project's conventions... but that's crazy, right?

    So anyway, I'd agree with argument #2, but not #1. For the little it's worth :)

  • ... Posted by Daniel Rosenberg Posted 01/24/2016 10:21 PM (Author)

    Ludovic: Welcome to the pig farm! ;)

    You make a really excellent point on #1, and I actually whole-heartedly agree with you!

    The same thought has often occurred to me. Pre-formatted text files are so primitive. I think a huge leap forward would be if code was not persisted as text files, but rather as some formatting-agnostic more normalized DOM-like format. Besides enabling each dev to write and read code according to her own preferences (including not also the fonts, colors etc. but also all the aspects you mentioned like brace positions etc.) imagine what other crazy things could be made possible, like grouping, sorting and filtering members of your class based on your preference or context without affecting the underlying source code, or viewing and editing the structure of your whole code file in some more efficient form. As an aside, something like this is actually possible today in the little-known Visual Studio Class Designer, but of course, that one also just manipulates the underlying raw text file.

    Alas, we are not there yet (and I suspect the minds of developers will never be comfortable enough with such a concept to allow that development to happen) but, just because tooling doesn't allow customization of all those other things, is that a reason to not take advantage of what little flexibility it currently does allow? In other words, isn't your point really that you wish we could take it even further and if so, why not start with tabs?

  • ... Posted by Bertrand Le Roy Posted 01/25/2016 07:07 AM

    There actually is tooling that enables that today.

    Anyways, how about acknowledging that this question and similar others are matters of taste, and as such are subjective? Instead of pretending that our reasons to prefer X trump other people's reasons to prefer Y, we accept our differences, make collegial decisions in our projects, accept them, then move on to more important matters?

    It's fine to explain why you prefer Y, but the ensuing discussion seems so pointless... Plus, you're clearly wrong.

  • ... Posted by Daniel Rosenberg Posted 01/25/2016 03:58 PM (Author)

    Wow, talk about being a dick Bertrand! Thank you for telling me what's fine to write about on my own blog, Mr. Moderator-of-the-Internet. :) Explaining my preference is exactly what I did - the "ensuing discussion" was in fact started by you! First you enthusiastically engage in the debate and get the comment thread started, and then two days later you call the whole discussion pointless?

    I for one find the discussion interesting and constructive - nobody is forcing you to participate, the Internet is a big place. :)

    The suggestion to "accept our differences, make collegial decisions in our projects, accept them, then move on to more important matters" is such a platitude - we are all already doing that, it's simply a necessity. That's not what this is about. Outside of the practical necessities of the daily grind, there is also space to debate things and question things at their core, practical applications be damned. This post is not an attempt to impose any practice onto any particular project. Those are completely different things. Plus, you're clearly wrong.

  • ... Posted by Bertrand Le Roy Posted 01/25/2016 05:13 PM

    Wow, dude, 100% joke o_O

  • ... Posted by Daniel Rosenberg Posted 01/25/2016 05:17 PM (Author)

    Oh, ok. Could've totally fooled me, but in that case, so was my response. :)

  • ... Posted by Bertrand Le Roy Posted 01/25/2016 05:18 PM

    FWIW, you've convinced me that your preference is an entirely valid choice.

  • ... Posted by Daniel Rosenberg Posted 01/25/2016 05:28 PM (Author)

    Now that actually really made my day - thank you for saying that! That's really all anyone could hope for - I have no illusions about being able to convince anyone to actually switch teams in these religious matters, but if my post is able to at least make a spaceman recognize that tabs are also a valid choice, then it was all worth it.

  • ... Posted by Capturous Posted 10/27/2017 10:52 AM [http://www.capturous.in]

    Ya it's a right tabs are better to use .

  • ... Posted by Gyaan Shree Posted 01/01/2018 07:32 AM [http://gyaanshree.com/]

    As you can cutomize tabs but not spaces . tabs may be in single page for different purpose, tabs play automatic good role in mobile responsive desing.

Leave a comment