Tabs vs. Spaces … and how many?

Published by Marco on

Encodo has long been a two-space indent shop. Section 4.1 of the Encodo C# Handbook writes that “[a]n indent is two spaces; it is never a tab.”, even though “[t]he official C# standard […] is four spaces.” and that, should you have a problem with that, you should “deal with it.”

Although we use our own standards by default, we use a customer’s standards if they’ve defined their own. A large part of our coding is now done with four spaces. Some of us have gotten so accustomed to this that four spaces started looking better than two. That, combined with recent publicity for the topic[1], led me to ask the developers at Encodo what they thought.

  • Urs was open to the idea of using tabs because then “everyone can use whatever he likes and we can avoid the unnecessary discussion about the ideal value (why does it have to be an even value? I want 3 spaces!!!) Further, we might be able to save some disk space ;)”
  • Sebastian was emphatically not open to the idea of tabs because “Tabs is just a lie. There are never only tabs. I’ve seen multiple projects with tabs, there are always spaces as well and this breaks the formatting depending on your settings.”
  • Wadim pointed out that “the tab key produces a character that is used for indentation”—heavily hinting that people who use spaces are doing it wrong—and then backed up Urs by suggesting 3 spaces per tab.
  • Fabi cited Death to the Space Infidels! by Jeff Atwood, “What does matter is that you, and everyone else on your team, sticks with those conventions and uses them consistently,” then expressed a preference for two spaces, but agreeing that four might be easier since that’s the standard used by other companies.
  • Remo backed up Sebastian in saying that tabs are bad, writing that “I have worked on projects where we tried to use tabs. But this always ended up in chaos somehow.” Two or four is fine—the longer you work with one, the odder the other one looks. “Personally I think using 2 or 4 spaces takes some time getting used to it. After that, both are well suited to read code with a slight advantage for 4 spaces because the “column” widths are wider and it’s therefore easier to find the closing braces when scanning vertically (our screens are really wide − so the loss of valuable space is no longer an argument).”
  • Pascal was along the same lines as Fabi. He made a good point for spaces, writing “I personally prefer spaces since it takes the whole configuration in all the tools out of the picture at once.”
  • Robin also pleaded for consistency above all, writing “I like tabs more” and “I’m used to a width of 2 spaces”.
  • Marco see the advantage of tabs for customization, but understands that it will probably lead to time wasted converting whitespace. He’s accustomed to 2 spaces and Encodo has a ton of code with two spaces. Although Fabi says he sees a lot of code with four-space indents, Marco’s seen a lot of code with two-space indents.

So, with the rewrite of the Encodo C# Handbook in progress, what will be our recommendation going forward?

Let’s summarize the opinions above:

  • Consistency is paramount (Fabi, Pascal, Robin,…pretty much everyone)
  • Using tabs has, in the past, inevitably led to a mix of tabs and spaces (Marco, Sebastian, Remo)
  • An indent of 3 spaces would be nice (Urs, Wadim)
  • Everyone else likes either a four-space indent or two while others don’t really care either way. Nobody wants eight[2].

So, we have emphatic arguments against switching to tabs instead of spaces. Although there are good arguments for a 4-space indent, there are also strong arguments for a 2-space indent. There’s no real pressure to switch the indent.

Encodo’s 2009 recommendation stands: we indent with two spaces. Deal with it.[3]


[1] If you’re watching Silicon Valley, then you probably already know what prompted this discussion. The most recent episode had Richard of Pied Piper break of a relationship with a girl because she uses spaces instead of tabs.
[2] As Richard of Pied Piper recommended, which is just insanity.
[3]

We use the EditorConfig plugin with all of our IDEs to keep settings for different solutions and products set correctly. The config file for Quino looks like this:

# EditorConfig is awesome: http://EditorConfig.org

# top-most EditorConfig file
root = true

# Unix-style newlines with a newline ending every file
[*]
indent_style = space
indent_size = 2