Why tabs versus spaces matters

Posted at 08:00 on 15 November 2010

Getting worked up about tabs versus spaces and consistent indentation may sound completely over-the-top OCD to some people, but there are very good reasons for it. It doesn’t matter too much whether you prefer tabs or spaces, but you must never mix the two in your code. Here’s why.

Inconsistent indentation is a menace when you’re trying to see what your code does.

The reason why we indent code in the first place is so that we can see unambiguously, at a glance, where a block of code, such as an if statement or an HTML <div> tag, begins and ends. It helps us to speed-read code and zoom out from the details to the higher level design with less cognitive overload. Without clear, consistent, unambiguous indentation, it’s easy to end up getting your code muddled up and introducing bugs.

Another problem is that different editors and other tools treat the tab character within your file in different ways. Some of them display it as four spaces, some of them as eight, and some people configure it to display as something completely different altogether. If you’re mixing tabs and spaces within the same function, it can look really confusing if for some reason someone has to load it up into an editor or other tool that behaves differently from what you’re normally used to. Such as, for instance, your source control’s diff/merge tool, or a web-based system such as Trac.

Inconsistent indentation is a menace when you’re merging changes.

If your indentation is inconsistent, sometimes my only option is to reformat it just to make sense of what's going on. Even when I don't, the chances are high that Visual Studio will do it for me. But this causes other problems. When your source control tool merges changes, whether you’re using svn update or hg merge or whatever, it does so by comparing your code on a line-by-line basis. If you change a line from tabs to spaces or vice versa, or increase or decrease the indentation by so much as a single space, it views it as deleting one line and replacing it with another. Consequently if you’re changing between tabs and spaces all over the place, you’re going to be setting yourself up for Big Scary Merges.

Most visual diff tools give you the option to ignore whitespace when you’re comparing files, but it still makes it much more difficult to carry out the merge, since you will get more conflicts when you attempt to merge the changes automatically.

Always turn on visible white space.

The first thing I do whenever I install a new editor is to turn on visible whitespace, and I always recommend other people to do the same, so you don't miss monstrosities such as this:

Some people object to this, saying that all the extra dots and arrows makes their source code look cluttered. This is a valid point -- Visual Studio’s default colour scheme does make it look rather intrusive. If you find this to be a problem, try changing the colour of your visible whitespace to something a bit lighter. You can get away with it being quite faint: just as long as it is enough to bring to your attention any inconsistency between tabs and spaces here, or trailing whitespace at the end of a line:

Even so, working with visible whitespace can take a bit of getting used to. But get used to it you must. Otherwise you’re just going to cause confusion and make life difficult not only for yourself but also for anyone else who has to work with your code.