&. |

Warning: I wrote this blog in 2009. That is a long time ago, especially on the internet. My opinions may have changed since then. Technological progress may have made this information completely obsolete. Proceed with caution.

Time to discuss something controversial that leads many geeks to commit acts of heinous violence. I’m talking about programming style!

So there are three basic ways to write if/elseif/else statements in most languages with C-like syntax:

Style A

if(condition1)
  statement1;
else if (condition2)
  statement2;
else
  statement3;

Style B

if(condition1) {
  statement1;
} else if (condition2) {
  statement2;
} else {
  statement3;
}

Style C

if(condition1)
{
  statement1;
}
else if (condition2)
{
  statement2;
}
else
{
  statement3;
}

Personally, I go for the most readable and maintainable code, so I use Style A iff all conditions and statements are trivial (by which I mean, they are short and fit on one line). Otherwise I use Style C. (Which you can see, for example, in that gradient-generator source I posted a few weeks ago.)

I’ve posted on my preference for Style C over Style B before, and I’m not going to focus too much on that here today. However, I continue to see Style B promoted as the universal, be-all end-all solution. It is recommended by Sun for Java, and by Zend for PHP.

The argument for preferring Style B over Style A usually goes something like this:

What if you come along and add a new line?

if(condition1)
  statement1;
else
  System.out.println("Condition1 failed!");
  statement2;

Now statement2 gets executed everytime!

The argument makes sense from an academic standpoint, but I am pretty sure this almost never ever happens in practice. The reason for this is that anyone who has been programming for more than a month will immediately see that this code won’t work as designed. It is a glaring bug that jumps out at you. It is nearly impossible to overlook! (Again, this is all assuming that the conditions and statements are all trivial.)

Now, for the last four and a half years my job has been primarily to fix bugs in a huge body of code, very little of which was written by me. For the last two and a half years, in particular, I’ve been the guy who looks at build traces and unit test results from the previous night. And when there are build or test errors, I have to look at recently changed code and decide who is responsible. This means I have seen most of the errors made by a group of about fifty or so programmers. That is to say, real-world errors made by real programmers, not hypothetical errors that might be made by a theoretical programmer. So I think I am reasonably well-qualified to have a strong opinion on the matter.

With that in mind, I’ve never seen an error that was due to the use of Style A for trivial statements. I have seen some downright ugly code that used Style A inappropriately, with conditions that were ten lines long. And I’ve seen ugly code that has braces on the if block but not the else block (or vice-versa). And I have seen several errors in Style B or Style C that result from intermingling of tabs and spaces. This happens because simple editors like vi and Notepad render tabs that are up to 8 characters wide (per spec, I might add), but advanced editors usually break spec in favor of user-friendliness, rendering tabs at 2 or 4 characters wide (or whatever the user sets them to). So if code was written using 4-character tabs in Visual Studio, then new code is added by someone using spaces in vi, and this happens back and forth a few times, you get indentation that jumps all over the place. This is where I think Style C is better than Style B, because it is easier to find the matching open-brace because usually the opening and closing braces are written by the same developer with the same indentation level, even if the code between the braces jumps all around. Also, with Style B, at a glance the code looks like indentation is wacky, since you have to actually read the previous line (or scan to the right end of the previous line) to find out if the developer actually intended the indentation to increase there, or if someone just increased indentation because they were using a different editor.

You can tell me why you disagree with me, and I am fully aware that there will never be agreement on this point; however, I’ll continue to avoid Style B until my pay is docked for it. Someone has to stand up for what is right.