The conditional operator (? :)

Every now and again I see a piece of code where the author has used the conditional operator ? : . It might be my tidyness or it might take some getting used to, but I don't like it. I don't like it at all! My gut feeling says it's nasty, because it's not easy readable code. Lets look at an example. Imagine you have a property getter for the count of a collection. When the ArrayList you use internally is null, you want to return 0, else you want to return the count of the internal ArrayList. With the conditional operator, this looks like this:

return (myArrayList == null) ? 0 : myArrayList.Count;

where 'complete' code writing would look like this, maybe even with an extra variable for the return value and just one return statement. (notice the brackets which you should always use imho):

if (myArrayList == null)
{
    return 0;
}
else
{
    return myArrayList.Count;
}

Although the first code sample is much shorter, you also loose a lot of clarity by using the conditional operator. The second code sample explains what is being evaluated and when what value is returned. In short: I think the conditional operator needs two or three times reading to be sure what is being returned when, where the other sample doesn't.

Sure, in this case the code might be simple to understand, but what happens when the expression being evaluated gets larger and more complex?

Published Wed, Jul 20 2005 10:07 AM by Rick van den Bosch
Filed under:

Comments

# re: The conditional operator (? :)

It just takes getting used to. I use this operator when it's clear what you're doing.

And it's a matter of taste. I would never write the 'complete' code your way. I would write it this way:

if (myArrayList == null)
{
return 0;
}
return myArrayList.Count;

The else is not necessary in this scenario.

This is why I think coding standards should never include rules about this sort of thing. Too much discussion, with very little value :-)

Wednesday, July 20, 2005 1:30 AM by Jan Schreuder

# re: The conditional operator (? :)

[quote]Too much discussion, with very little value[/quote]

That's true. And indeed it might take some getting used too, like I also said in my post.

About the 'complete code': I wouldn't want to say my code is the only right implementation. You might want to add a variabele to store the count and return that one, you might want to leave out the else like you did, or you might want to take a different approach.

Although I think the else makes it more clear that that return statement is only hit when the if wasn't met...

Here we go again with the discussion ;)

Wednesday, July 20, 2005 1:43 AM by Rick van den Bosch

# re: The conditional operator (? :)

I really do not have a preference either way, I use it myself on occasion there are just some spots it just seems appropriate to me. If I am doing anything extremely complex with a lot of math then I do break it into an if statement.

Wednesday, July 20, 2005 5:41 AM by Jeff Parker

# re: The conditional operator (? :)

I agree with Jan on the coding style. This style becomes more important if you have multiple if statements that follow each other.

I prefer to limit the amount of nesting of code inside else statements. So I avoid the else block when the code in the if block returns and the else is not required.

Of course this requires that you are not of the religion that only one return statement is allowed per method ;)

Wednesday, July 20, 2005 2:55 PM by Erwyn van der Meer

# Defensive programming

We all encounter them in the field: pieces of code that are based on assumptions. There's something fundamentally wrong in assuming when writing code.

Thursday, February 08, 2007 3:59 AM by Gump's blog

# Defensive programming

We all encountered them in the field somewhere along the way: pieces of code that are based on assumptions. There's something fundamentally wrong in assuming when writing code.

Wednesday, February 14, 2007 7:26 AM by Gump's blog

Leave a Comment

(required) 
(required) 
(optional)
(required) 
Please add 3 and 7 and type the answer here: