Tabs vs. Spaces: Why is there a Debate?

Whether to use tabs or spaces when indenting code has been a source of contention among developers for some time. However, in none of these debates have I found a legitimate reason for spaces instead of tabs — at least not when both sides have a firm understanding of how tabs are to be used (i.e. indentation, not alignment).

Advantages of Tabs Over Spaces

So, why do I prefer tabs over spaces? It’s quite simple: there are a huge number of advantages and very, very few reasons to use spaces — namely to work with teams that are stuck in their ways.

1. Fewer Key Strokes

This one should be obvious. Pressing the tab key on the keyboard is only one keystroke. Unless you indent with only one space (which is bad for other reasons), you’re spending more time typing. Now, I hear you saying that almost all modern code software can automatically replace a tab with a certain number of spaces. Let me say that this isn’t a solution; it exacerbates the problem and makes it nearly impossible to insert an actual tab character. It’s just a patch to a problem and misleads people into thinking that white space isn’t important — until they work with someone else’s code, who didn’t use the same number of space characters as the “auto-space” feature in their editor.

2. Easier Keyboard Navigation

Even if your editor does replace tabs with spaces, it usually doesn’t change how the arrow keys navigate through those characters. With tabs, I can use the left/right arrow keys to move back or forward one level of indentation with each key press. This doesn’t work with spaces, and if you’ve only ever used spaces, you probably don’t even realize how inefficient it is.

Many hard-core coders will point out that there are editors such as Vim with very efficient keyboard navigation that doesn’t rely on the arrow keys or that you can use keyboard shortcuts (like ctrl+left arrow) to move through white space, but not everyone uses those editors (or is proficient with them), and shortcuts are often still more complex. Even so, the ability to move from one level of indentation to another is not addressed.

If you’ve worked with spaces your entire career, then you probably think that being able to navigate quickly through levels of indentation is a minor boon. You’ve probably learned to naturally compensate by using your mouse and clicking to place the cursor where you want or some other keyboard combination. However, tab users immediately recognize how painful it is to move through code with spaces. It’s like switching from a two-button mouse to one with only one button — why would anyone do that?

3. Smaller File Sizes

Both space and tab characters take up one byte of space. If you use two spaces to indent, you’re doubling the file size of your documents, and you’re more likely quadrupling the size since many editors default to four spaces per tab.

Most space apologists will claim that code can be minified or compressed in some way, but let’s be realistic. Take a look at the source code of just about any website’s HTML that relies on spaces for indentation, and you’ll find that the vast majority are not compressed. Even when they are, the original source exists somewhere and is taking up disk space. Storage may be cheap, but that’s not a good reason to fill it up.

4. Configurable Indentation Preferences

Suppose I like four spaces per level of indentation, but my colleagues prefer three. We’re eventually going to have to negotiate on one or the other, and if I’ve been using four spaces, then it’s going to be hard to break that habit. This leads to inconsistent, sloppy code. Even if I eventually adopt my team’s standard, what happens when I move to another team or inherit a project from other developers? It also means that any new team member will also have to adopt our version of the acceptable number of spaces.

If you were to use tabs, you wouldn’t have this problem. Each developer can configure their environment to use a specific tab width; whether it be two, four, or even eight spaces. This makes everyone happy. Imagine if you forced everyone to use a specific font size or syntax highlighting. Obviously, these things don’t impact the quality of the code, so why not let everyone customize them to their own personal preference? Why are you being a white space Nazi?

5. Readability

Quick question: How many levels of indentation are there in the line with the //Case 1 comment?

····for (a = 0; a < b; a++) {
········switch (c) {
············case 1:
················// Case 1 (WHAT'S MY INDENTION LEVEL?)
············case 2:
················// Case 2
················break;
············default:
················break;
·········}
····}

Did you get four? If so, it’s because you had to read the surrounding code to figure it out. Now, let’s try it again with tabs.

--->for (a = 0; a < b; a++) {
--->--->switch (c) {
--->--->--->case 1:
--->--->--->--->// Case 1 (WHAT'S MY INDENTION LEVEL?)
--->--->--->case 2:
--->--->--->--->// Case 2
--->--->--->--->break;
--->--->--->default:
--->--->--->--->break;
--->--->}
--->}

See how much easier that was? Each tab is one level of indentation. With spaces, we’re at the mercy of the developer and whether he/she was consistent with the number of spaces. Finding errors with improperly nested code is much easier when tabs are used. You can’t accidentally forget a part of a tab, but you can easily enter three spaces instead of four.

By the way, I purposefully made a mistake in the number of spaces for one of the lines in the first example. Did you catch it? Would you have missed it if I had used tabs?

Why Spaces are Problematic

1. No Consensus on Amount of Identation

We touched on this in briefly in the points above, but it’s important enough to get its own section. No one agrees on how many spaces make up one level of indentation. Standards are important when it comes to code. Just because your team has come to a decision on a set number of spaces per indentation, doesn’t mean that they’re all happy with it, that they’ll all honor it, or that the decision will work on anything other than new, start-from-scratch projects.

With tabs, there’s only one decision to be made: tabs or spaces. With spaces, there’s tabs or spaces, and how many spaces. Given the advantages of tabs outlined above, I don’t see why this should be a hard choice.

2. Not Portable

What do I mean by “not portable?” I mean that if you share your space-indented code with anyone else (e.g. all those online tutorials where you can copy/paste the code), the recipient is going to have to reformat it for his/her environment. People that use spaces instead of tabs think that this is just par for the course, but tab users have a big advantage here — they can use the code as-is. Worst case, they may need to change the indentation level, but they’ll certainly never have to go through each line adding and removing spaces. And don’t say, “editor X handles this fine.” Wait until you have to work in a client’s environment where only Notepad is available.

3. They’re Hard to See

Spaces are a poor fit for indentation simply on the fact that you can’t easily see an individual space character among groups of spaces. How often have you been typing an Office document where you had to do a double-take to see if you had typed two spaces instead of one? Granted, this isn’t as much of a problem with fixed-width fonts, but it’s still a problem.

I absolutely hate it when developers use only one or two spaces for indentation, and it’s not because of bad eye sight. If your HTML or XML is so complex that you need tens of levels of indentation and it’s interfering with the available horizontal space in your editor, then you’re doing something wrong. If you must use spaces, use at least three or four.

Hopefully, you code with visible white space markers. If not, then maybe that’s why you don’t see the problem with spaces. In Visual Studio, use ctrl+r ctrl+w to show white space. In Sublime Text 2, add the “draw_white_space” setting to your user preferences and set it to “all”. If you’re a serious coder, then you should have a consistent use of tabs and spaces, where tabs (usually denoted by arrows) represent the level of indentation and spaces (usually denoted by dots) represent alignment characters. Here’s an example:

--->var myObject = { color: 'red',
--->·················size: 'small',
--->·················shape: 'circle'};

This seems to confuse a lot of people in the space camp. It should be easily noticeable that the code above has one level of indentation and that spaces have been used to align the “size” and “shape” properties so they line up nicely. For some reason, the space people claim this as something that can’t be done with tabs, and then they try to demonstrate their point by incorrectly using multiple tabs to align the properties. They don’t seem to understand that tabs are only for indentation. Spaces are for alignment.

So Why are Spaces Used so Often?

With all these advantages, why are there so many advocates for spaces? Here are a few possible reasons.

1. Misunderstanding of Difference Between Indentation and Alignment

Some people have a hard time knowing when to use spaces and when to use tabs, so for them it’s easier just to use spaces all the time. This is a cop-out, and if it’s your excuse for using spaces, then you need to learn the difference.

2. Code Editors that Replace Tabs with Spaces

Many code editors, Visual Studio included, default to replacing tabs with spaces and not showing white space characters. This leads to ignorance as to what is actually happening behind the scenes, and novice coders never learn to use tabs as they’re meant to be used. It also leads to a mixture of tabs and spaces that only looks good when viewed in the original editor.

3. Copy and Paste Programmers

Many developers learned how to write code by pasting it from other sources. Unfortunately, Web browsers aren’t the best at displaying code, and Web authors weren’t sure how to insert tab characters into their tutorials. This means that a large majority of the code that is shared online uses spaces instead of tabs.

4. Sloppy, Indifferent, and Poorly Organized Coders

Many programmers don’t care about what their code looks like. “As long as it works” is their mantra. These people are usually disorganized and write code that is difficult to maintain. They are entrenched in a specific code editor and are highly resistant to change or anything that jeopardizes their current method of writing code.


I hope you don’t fall into that last group and that you care about how your code looks. Well written code should be quick to create, easy to maintain, and it should look beautiful. Maybe that last bit isn’t important to you, but maybe you’re not passionate about what you do either. Use tabs for indentation. Spread the word.