To bracket or not to bracket, making sense of single line conditionals
It’s taking me about 3 months to finally come up with a strong opinion about single line conditionals, but I now have a firm position:
“In the long run, it’s a bad idea to drop the brackets and put a conditional or iterator on a single line.”
Essentially sort of thing:
public function testResults(score:Number):void
{
if(score < MIN_PASS) sendNotification(YOU_FAIL)
else sendNotification(YOU_PASS)
}
Should always be this:
public function testResults(score:Number):void
{
if(value < MIN_PASS)
{
sendNotification(YOU_FAIL)
}
else
{
sendNotification(YOU_PASS)
}
}
Even when writing in a language that doesn’t use brackets, i.e. so called pure block languages like Python and Visual Basic, proper formatting should be used rather than single lines. If a language does use brackets, there is no excuse not to use them.
My argument follows this logic:
“Since debugging code is 20 times harder than writing it, by that definition you won’t be smart enough to find errors in clever code.”
Single line conditionals are essentially clever ways to save line space and avoid using brackets. As such, they cause an extra level of structured complexity that can be unfamiliar and confusing in a fully realized code based.
There are a lot of coders who might disagree with this, but I have good reason for taking this approach. First of all, one line statements are dense, hard to read and uncommon enough to be awkward.
That’s not to say they don’t look great, because they do. But they are a guilty pleasure to write because they belie the complexity of the code. And as a number of seasoned professionals might tell you, readable code always super cedes pretty layout.
Certainly the instance above is a modest example, but think of what happens when these are spread freely in classes or routines a couple hundred lines long. The logic is literally packed into dense statements whose size hides the real length of the program.
The reader tricks themselves into believing that because line-for-line the statement is smaller that it is easier to read. However, in reality the layout removes all visual cues that tell a programmer they are dealing with a control structure.
To state it firmly, the number one objective of any coder should be to reduce complexity, and this does the exact opposite.
I was attracted originally attracted to the single line approach because the extra lines and brackets can be annoying. I even started using it for looping statements*. But I noticed what was happening to my code, and even my own behaviour.
Brackets in this instance act as a natural defense to the proliferation of ugly, unplanned, haphazard code. Single line statements, because the mistakenly feel concise actually encourage bad coding practices.
Conditionals are twisting logic that arrest the normal intellectual flow of a program in the writer’s mind. They are necessary to be sure, but should be used as sparingly as possible to help simply the code base.
Because single line conditionals are so easy to write, they create an easy road that is often all to tempting when the logic gets tough, and you begin to realize you’ve been writing too many conditional control structures.
My new favourite quote is Anonymous:
Code as if whoever maintains your program is a violent psychopath who knows where you live.
*Side Note: Interestingly enough, Flex or Eclipse will not provide code completion for lopping variables not included in brackets.