Tom Lachecki

A programmer friend recently revealed that his company has a strict no-tabs policy, and that they are forced to use space indentation… at no fewer than eight spaces. This makes me sad.

The spaces vs tabs debate is an age-old one, with proponents on both sides fighting the cause as avidly as in the editor wars, browser wars, language wars and probably a bunch of others.

The spaces people argue that indentation should be applied by repeatedly pressing the spacebar key a certain, consistent number of times:

The tabs people, on the other hand, believe in pressing the tab key just once. This makes the next character align vertically to the next tab stop:

Personally I like to see code with its indents at 4-character widths, and when code has been indented nice and atomically with one tab per indent level, I can configure my editor to make that happen. When I make changes to the code and save it, the tabs are still there in place so the next reader could view it with tabs at 8-character widths.

With spaces, if I wanted to see a different amount of indentation I'd have to go through every line and add/remove spaces as required, and then that change would affect all other viewers of the code. It would also involve pointless updates to a version control repository.

Which do you use? If tabs, how far apart are your tab stops when you code? (For indentation, that is, which is the only time you should use them.) If spaces, can you explain the benefit to me? Please?

Update: Setting your client to insert multiple space characters when you hit the 'tab' key does not count. It's just a keyboard shortcut; you're still inserting space characters into your code that render a fixed, hard-coded amount of spacing.

Hi. I'm here to address the age-old debate of C and C++; which pointer declaration syntax to use?

Foo<em> ptr; // (1) Foo </em> ptr; // (2) Foo *ptr; // (3)

All three are equivalent because arbitrary spacing is meaningless in C/C++.

The problem with C and C++ is that its built-in operators have multiple meanings. In particular * means "pointer type", "multiplication" and "dereference". My goal when picking a convention is to, as much as possible, avoid using one that jars with another.

Therefore, we'll ignore syntax 2 because it looks so much like multiplication.

Unfortunately, there is no clear winner between the other two as each has at least one hindrance. Syntax 1 has the following:

Foo* ptr1, ptr2;

In the code above, ptr1 is a Foo*, but ptr2 is only a Foo. One might have expected both to be Foo*s. Syntax 3 avoids this by keeping the asterisk with the name:

Foo <em>ptr1, </em>ptr2;

This is really a throwback to C's desire to have you think in terms of "I am declaring a Foo to which ptr points".

Unfortunately, this is misleading to language newcomers because in fact you're not declaring or defining a Foo at all. You're merely declaring a pointer; you still haven't allocated any actual Foo for it to point to.

A newbie reading "int *a" might think he's created an int and now gets to use "the variable *a" to access it, when in fact this is not the case at all; dereferencing such an undirected pointer would be very dangerous.

Further, aligning the asterisk with the variable name looks like a dereference operation. One of the biggest stumbling blocks to language newcomers is the multiple meaning of operators such as * and & — learning the difference between * on the LHS as a pointer type indicator and * on the RHS as a dereference operator is not aided if you see code that always aligns the asterisk in the same way.

Additionally, the name of the type itself is "Foo*" (though array declaration and function type declaration syntax oddities do make this slightly more complicated in practice).

To summarise:

In conclusion:

Foo *p is rubbish; it has three cons and two pros. Foo* p is great; it has one con and four pros… important pros.

Thanks for reading.

Updated 31/07/2010: Improved table layout for clarity.