As promised, I’m weighing in on another burning issue of 10 years ago:

I recently overheard the utterance “@thomblake No one has any good reason to like \s indent. Either you like \t, or you don’t care. It’s not life-and-death, but \t is clear win” (via isaacschlueter on Twitter). I assented, as I really only started using space-indent because it’s a best practice at my workplace. But on reflection, I really do have good reasons for space-indent, based on the way that I use indentation in code.

When writing say, C code, I use 2-space indent for most things. This looks equivalent to tab-indent with the tab stop set to 2:

for (int i=0; i<5; i++) {
  something(i);
  something_else();
}

However, there are situations where this doesn’t work out so well. At the office, we use 80-character columns and linewrap is strictly prohibited, so complicated statements get offset (where possible) by indenting to the relevant brace:

int func (int argc, char **argv, map m) {

  ...

  for (int i=0; i<5; i++) {
    something(/* type */ TEXT,
              /* 1st  */ 1,
              /* 2nd  */ i,
              /* last */ 9,
              /* name */ "Fred",
              /* flag */ FL_FOO|FL_BAR|FL_BAZ|FL_HIP,
              /* froz */ m.asInt("zip"), 0);
    something_else(m("Fred").match("^(1|2|3|4)$")
                   || m("Bob").match("^((test|live)(1|2)?)*$"));
  }

  ...

}

One could not rely upon an editor to properly format this using tab characters. The number of spaces indented to “/* 1st */” must be equal to the amount of characters in “something(”. Of course, with the proper Emacs setup, the number of spaces to the open-paren can be filled in automatically using the tab-key.

Another reason I would use differing indents in code is when mixing programming languages in a source file. For example, in MXML I use 4 spaces and in Actionscript I use 2 spaces, for aesthetic reasons. It would make no sense to interpret that as “2 tabs and 1 tab” for other tab stops. (Not to mention the 3-space indent I use after a “<![CDATA[”.) For example:

<?xml version="1.0"?>
<mx:Application styleName="plain"
    xmlns:mx="http://www.adobe.com/2006/mxml"
    creationComplete="initApp()">

    <mx:Script>
        <![CDATA[
           private function initApp():void {
             for (var i=0; i<5; i++) {
               something();  //do something clever to box1
             }
           }
        ]]>
    </mx:Script>

    <mx:HBox id="box1" width="100%" minWidth="50" />

</mx:Application>

Yet another reason to use spaces rather than tab characters is for tabular layout (counterintuitive!):

[
[1,     900,    30,     ]
[40,    80,     200,    ]
[999,   22,     1,      ]
]

With a tab stop of 2, for instance, this table’s layout would break if it used tab characters.

One solution to this would be to mix tab and space characters. One could use spaces for the applications where tabs don’t do the job, and tabs for everything else. But that would be, at the least, annoying. With the proper setup, much of the work being done by spaces above can be done automatically by an editor using the tab-key; losing that functionality (or making it intelligently choose whether to insert tab or space) isn’t worth the trouble (neither is C-T for tab). And mixing tabs and spaces for indenting is not a good idea, since \t and \s are both whitespace characters, and thus the distinction will be missed by the naked eye.

For more thoughts on why space indenting is a good idea: Tabs versus Spaces.

And for someone who already responded to nearly all of my concerns: Why I love having tabs in source code. However, Why Tabs Are Evil agrees that mixing \t and \s in front of your code can lead to problems, and so the distinction between “indentation” and “alignment” might not be relevant.