But sometimes, things go a little too far. Like our enforced coding standards: I am now resident in an insane asylym where the coding standard is to have every brace on its own line.
Instead of:
if ($x) { doX();}
else{ doY();}
you must write:
if ( $x ) { doX(); } else { doY(); }
This, I am told, increases readability, carrying the direct implication that the former decreases readability. This assertion is like the assertion 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 either one isn't 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?
Coder: I'm trying to debug this program, but there are too many braces on the same line. I keep getting confused. And 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.
And now, by extension, so do I.
I far prefer the "braces on lines by their own" style; I think it works better in harmony with indentation and avoids vertical crowding.
ReplyDeleteOn the other hand, spaces inside the parentheses like that is disgusting! Not quite as bad as spaces before the parentheses in function calls (e.g. "sin (x) * cos (y)") but almost.
I prefer working in teams that don't have coding style enforcement, but rather hire people who have sensible coding styles (i.e. consistent and structured). Making all the code have the same style isn't important unless your product is an actual programming language and you're trying to teach your customers good style. Having distinct styles mixed in the one codebase has other advantages; it can act as a marker as to who wrote it. Source control repositories tend to have lifetimes measured in years rather than decades - they are not reliable for this in the long run - and besides, it takes time to run svn/git blame/etc.