Why you should Indent with Spaces

I avoid tabs in all code I write. That’s why you can read my code in your browser with the exact same formatting as it had in my IDE – no matter what browser or device you are using: Nuclex Framework sources in TRAC. Yet from time to time, I encounter people evangelizing tabs.

While I am fine with working on projects that use tab characters and I neither argue about the decision to use tabs nor intentionally divert from their style, I do have an opinion and it is that you should avoid tabs wherever you can.

Even the one, lonely, supposed advantage of tabs – users being able to choose their preferred indentation level – is a drawback in disguise because you no longer can set a safe limit for line lengths (see below).

• Tabs are inconsistent even on their own!

  One editor will interpret them as "insert 8 spaces here" another as "go to the next multiple of 8".

  Spaces, in contrast, always have the same effect in every place, editor and environment.

  But rejoice, efforts are underway to add yet another possible behavior for tabs: elastic tab stops which automatically change their width depending on context!

• Correct use of tabs requires OCD!

  If you use tabs for indentation, you still have to use spaces for aligning. So to make code look consistent across different tab widths, you have to do weird things like fill a line with tabs up to the current indentation level, then fill the rest with spaces:

  

  Of couurse everyone will remember this rule when they need to align their code and consistently mix tabs and spaces in just the right way.

• Your Editor Butchers your Code!

  Wait, did I just say mix tabs and spaces? I’ve used a lot of text editors and some helpfully ask me:

  

  Well, any choice other than Cancel will destroy your carefully arranged contraption of tabs and spaces from the previous section!

• Browsers will Indent like Crazy!

  When you view tab-indented code in a web browser, it will be indented by a ridiculous amount of space.

  

  Yeah, a handful of browsers have or are about to introduce an obscure expert setting you can use to tweak tab width.

  And Suure, all your visitors will use such a browser, be aware of that setting and will have it tweaked to their favorite tab width. Those visitors reading your blog/forum/publication on a tablet or smartphone with limited screen space will most assuredly have tweaked their browser settings.

• The Magical NoS-Injected Cursor

  Tabs become really nasty when you select things or delete code because, after leisurely advancing through your columns and lulling you into estimating the time when you will release the key, your cursor will suddenly speed up two- or four-fold and come crashing into the next line.

  I like my keyboard repeat rate set to max and I don’t know how often I accidentally killed a chunk of code because suddenly a tab-indented line hid somewhere in the code.

• No Safe Screen Size to Target!

  When you use spaces, you can set a hard limit for how long your code lines should be. Popular choices are 100 or 120 characters. That’s pretty damn useful because you can say:

  If your arrange your editor panes to display this many characters, you will never, ever have your coding disrupted by the need to horizontal-scroll.

  Now here come the tabs. Here are the rules tab-users would have to follow. Enjoy!

  1. For ensuring no horizontal scrolling at a maximum of 4 spaces per tab, at an indentation of 1, limit your line to 97 characters.
  2. For ensuring no horizontal scrolling at a maximum of 8 spaces per tab, at an indentation of 1, limit your line to 93 characters.
  3. For ensuring no horizontal scrolling at a maximum of 4 spaces per tab, at an indentation of 2, limit your line to 94 characters.
  4. For ensuring no horizontal scrolling at a maximum of 8 spaces per tab, at an indentation of 2, limit your line to 86 characters.
  5. For ensuring no horizontal scrolling at a maximum of 4 spaces per tab, at an indentation of 3, limit your line to 91 characters.
  6. For ensuring no horizontal scrolling at a maximum of 8 spaces per tab, at an indentation of 3, limit your line to 79 characters.
  7. For ensuring no horizontal scrolling at a maximum of 4 spaces per tab, at an indentation of 4, limit your line to 88 characters.
  8. For ensuring no horizontal scrolling at a maximum of 8 spaces per tab, at an indentation of 4, limit your line to 72 characters.
  9. …

• Tab users have Three cursor coordinates

  We can thank the tab character for the existence of this ugly wart:

  

  Where is my cursor? Oh, column 12. No wait, it’s at character 8! ’nuff said.

• Indentation-Delimited Languages Love Tabs! </sarcasm>

  There are languages that delimit blocks not by the famous sequences like {/} or BEGIN/END, but by whitespace alone. Python for example: Python PEP 8 Style Guide for Python:

  class Rectangle(Blob):
  
      def __init__(self, width, height,
                   color='black', emphasis=None, highlight=0):
  
      if (width == 0 and height == 0 and
          color == 'red' and emphasis == 'strong' or
          highlight > 100):
          raise ValueError("sorry, you lose")
  
      if width == 0 and height == 0 and (color == 'red' or
                                         emphasis is None):
          raise ValueError("I don't think so -- values are %s, %s" %
                           (width, height))
  
      Blob.__init__(self, width, height,
                    color, emphasis, highlight)
      

  So Python programmers can just forget about aligning things?

That’s my opinion on tabs. I’m aware that this post could possibly attract some heated arguments from those programmers who prefer tabs, but I needed to write this after working in a large, tab-using codebase for the past few days. I won’t bully anyone into using this or that style, but as to what’s superior – that matter looks pretty black and white to me.