Brace yourself: there's an argument coming

I am now resident in an insane asylym where the coding standard is to have every brace on its own line.

I'm a great believer in In House coding standards, especially anal coding standards, because they serve a valuable purpose: they give us a weapon with which to whip the juniors. But sometimes, things go a little too far. Like our enforced coding standards:

Instead of:

if ($x) { doX();}
else{ doY();}

you must write:

if ( $x )

This, I am told, increases readability, carrying the direct implication that the former decreases readability. This is like asserting that raising corporate taxes will cause economic ruin. It sounds right, but it's never been put to the test. Likewise, I have yet to see any evidence that one brace convention is more readable.

Really, are we all children? If we don't see the braces on their own line, do we panic and spill our coffee over the keyboard? Has either one been the source of bugs in any program?

Manager: You've been working at your desk nonstop 16 hours. What's going on?
You: I'm trying to debug this program, but there are too many braces on the same line. I keep getting confused.
Manager: Deep breaths. Take deep breaths.
You: But it gets worse! There are all these braces that are on their own line. I don't understand why they are there.
Manager: A program with braces on the same line as the function AND braces on their own line. (picks up phone) Ted, you better wake up the President.

The real reason we have these arguments isn't based in rationality. There is no correct answer. The real reason we have these arguments is that most coders are autistic to some degree. Putting function braces on their own line is more than just a preference for them. It's how they live their lives.

In the same way that the Rain Man absolutely had to watch Judge Wapner every day, developers absolutely have to code in the specifically prescribed manner.

No comments:

Post a Comment