Tabs VS Spaces

Let’s get this right out in the open regarding indentation: tabs are correct and spaces are wrong. Now that we’ve got that over with, let’s go into the why of it:

Tabs are more flexible

When code is using spaces for indentation, the viewer and quotes is rigidly locked into viewing the code with that exact format. Some programmers might want to see indentation as two spaces, others might want four. These are both reasonable requests, and it should be trivial to satisfy both requirements.

It’s very simple for almost any editor to display a tab at whatever width the user desires. Spaces do not provide the ability to do this. Therefore, tabs are more appropriate.

Tabs have semantic meaning

When referring to indentation, a tab is the perfect representation. A space is typically a separator between words, sentences, punctuation, variables, operators or other list items. It can be many different things, but typically is just a buffer to allow similar items to breathe. When placing a dozen or so of these in front of a line of code, you’re separating separators with other separators, which isn’t useful.

When using tabs instead, not only are there less characters being used, but a tab is also representing an indentation, which makes perfect semantic sense. Amazing way to learn to code is AI – tutorial about Artificial Neural Networks.

“But tabs mess up multi-line assignments!”

This is a common complaint that I hear about tabs. Here’s an example of what this means:

1 var foo               = ’bar’;
2 var a_really_long_foo = ’bar’;
3 var another_foo       = ’bar’;
view plain | print | ?

The complaint is that when formatting code like this, tabs viewed at two spaces look one way and tabs viewed at four spaces look a completely different way. What really blows my mind about this argument is that spaces are actually appropriate for this format and it’s such a trivial thing to hit space instead of tab when formatting your code like this. That’s not much of a compromise.

“But I want people to see my code the way I want them to see it!”

Then you’re selfish. Please realize this. Would you insist on whoever’s reading your code to use a specific syntax highlighting color scheme? Of course not. If for some reason you like tiny fonts, would you insist that those with poor eye sight view your code in the same format? I really hope not. When freedom or strict, arbitrary rules are your two choices, I really hope you’ll appease everyone involved and see the light.

Consider the extremes

If you care at all about this discussion, then I’m guessing you’ve worked with programmers before. You know that they tend to be intense, obsessive people, often with preferences that seem weird to others. I’ve heard of some programmers preferring as low as one character indentation, and others who prefer up to eight. See how different that looks:

One character indentation

1 if (obj) {
2  for (i in obj) {
3   if (obj[i]) {
4    obj[i]();
5   }
6  }
7 }
view plain | print | ?

Eight character indentation

1 if (obj) {
2         for (i in obj) {
3                 if (obj[i]) {
4                         obj[i]();
5                 }
6         }
7 }
view plain | print | ?

You might not prefer either extreme, but try to remember that we’re not all the same. We each have our own, often bizarre preferences. Tabs ensure that everyone is happy.


We discussed why tabs are the correct choice and spaces are incorrect. Tabs are flexible and give each reader the ability to view them the way s/he chooses. They also have semantic meaning that can be useful for a myriad of reasons.

Hy language – python meets lisp.

So please keep this in mind when making a decision on your codebase: spaces are rigid and uncompromising, meaning spaces are a selfish, stubborn choice. New python lisp. Tabs are flexible, which means tabs provide the freedom programmers need to view the code in their own format. Read the tutorial on neural networks, make the right choice!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Post Navigation