Why Shouldn’t I use TAB Characters in My Source Files?

<Shudder>

No, this has nothing to do with platforms. All use hex 0x09 to represent a
tab character.

The problem is much, much deeper than that.

This is about programmers, religion, and the meaning of that lowly
little character we call “tab”.

I shudder because I’ve witnessed religious flame wars between computer
programmers on this issue. Seriously.

To understand why something this seemingly simple would inspire deep
passion, we need to define a few things. Like “tab”. And in doing so, we’ll see
that there is no one true definition. Only the one you choose to adhere to.
(It’s sounding like religion already!)

First let’s separate out two concepts: the tab character and the
tab key. They’re not the same. That’s part of the confusion.

TAB: The Character

The tab ASCII character, hexadecimal value 0x09, decimal value 9, probably
dates back to the days of the teletype. As defined by how the hardware was
constructed, a tab character moved the print head to the next tab stop, which
was the next multiple of 8 character positions. If a tab was encountered as the
teletype printed, the print head would jump ahead to column 9, 17, 25 and so on
– whichever one was next.

Put another way, a tab character was hard-coded to be every 8
columns. And you can’t get much harder than hardware.

My guess is simply that the tab was a convenient form of compression. A long
run of blank space could be described by a much smaller number of tabs followed
by an appropriate number of individual single spaces.

Indenting: The Root of the
Controversy

Let’s step away from the tab character issue for a moment, and talk about
indenting. Indenting is an approach to making programming code, be it HTML, C,
Basic, or who-knows-what, easier to read by laying out the individual
instructions in a manner that visually mimics the intended structure of the
code. For example:

if (1 == a)
    printf ("'a' is one\n");
else
    printf ("'a' is not one\n");

This silly little snippet of code uses indentation as a visual aid to show
the structure of the ‘if’ statement. This is equivalent:

if (1 == a)
printf ("'a' is one\n");
else
printf ("'a' is not one\n");

but as you can see it’s much harder to get a sense for what’s happening.

Now the controversy. How many columns should indented lines be indented? My
example above is 4. Here’s that same example with an indent of 2:

if (1 == a)
  printf ("'a' is one\n");
else
  printf ("'a' is not one\n");

and again with an indent of 8:

if (1 == a)
        printf ("'a' is one\n");
else
        printf ("'a' is not one\n");

Which is “better” is a matter of personal taste and readability. I have
seen, and at various times used, intents of 1, 2, 3, 4 and 8. And while it
sounds silly to some, programmers do get passionate at times as to how much to
indent – this is code they have to look at every day, and they want it to be as
readable and understandable as possible. Indenting is part of that.

In particular, when you have multiple programmers working on the same source
code, it’s critical that they agree on how much indenting they’ll use. Why?
Because if some indent at 2, and others indent at 4, for example, the code will
over time become more and more difficult to read. And that, in turn, makes the
code more fragile and error prone.

The Tab Key: A Solution, and
Yet…

It’s easy to indent to any column just by typing the spacebar the
appropriate number of times. However that quickly gets cumbersome. But what
about tab?

If you can standardize on an indent of 8, well then having the tab key
insert a tab character, and then just typing tab the appropriate number of
times will get you right to your level of indent. Very quick, easy to use, easy
to do.

But what if your indent style isn’t 8? What if it’s 4? Or 3?

Two different approaches are commonly used:

Redefine the tab character, and still have the tab key
insert a tab character: Many, if not most, text editors will allow you to
redefine what the tab character physically means. So many programmers will
simply use this to say “a tab character means tab stops every 4 columns”. Then
they define the tab key to insert a tab character. Very quick, easy to use,
easy to do. But it only displays properly if that redefinition of tab is
used. If someone else who hasn’t defined the tab character to be every 4
columns looks at the file, the indentation will be wrong. Things won’t line up
properly.

Redefine the tab key, and leave the tab character
definition alone. Many, if not most, text editors actually understand that
“indent” is a different concept than “tab”. By assigning the tab key
to some kind of smart indent feature in the editor, the computer can simply
automatically insert the correct number of tab characters and spaces to move to
the desired indent column. For example, if you want to indent to column 13, the
computer would simply insert one tab and 4 spaces, without you’re having to
think about it. Once again simple, efficient, allows you to use tab characters
according to their default definition, and makes the computer do the work.

The Third Option: Kill the Tab
Character

The problem is that those two different approaches are, indeed, commonly
used. That means that you may well find programmers who have their text
editors, viewers and other tools to assume that a tab character means every 3
spaces. Or every 4. Or every 8. And that means that any file that contains
tabs, regardless of the definition may not display properly for
everyone.

It’s important to have a public convention that says “tab characters mean
this”, so that when someone views a file they can adjust your settings so that
it will view properly, but still… that’s cumbersome and easily forgotten,
especially for folks that move between projects that have different
conventions.

One solution is simply to avoid the problem. Don’t use tabs. Indent to
whatever degree your convention calls for, just use spaces to do it. Let your
text editor simply insert the appropriate number of spaces to get to the next
tab stop.

That way, all files that are tab-free are guaranteed to display properly no
matter what your tab character is defined to be.

The cost? Your source files will be a little bigger. A trivially small cost
in today’s environment of huge disks and storage.

Who’s Right?

So what’s the answer? Who’s right?

Everyone. No one.

Regardless of how we got here, here we are. The tab character does, and
doesn’t, get redefined. People do use mixes of tabs, tabs and spaces or only
spaces to indent their code.

What’s most important is that everyone working on the same source
code use the same convention, and that the convention is somehow documented and
easy to find, so that others looking at, or perhaps about to work on the code
can adjust their own settings, if needed.

And I say that as someone who’s been a referee on too many of these coding
standards religious battles.

(And I won’t even touch the issue of where the curly braces go in
programming languages like C or C++. :-)