Coding standards and the ternary conditional operator

[Robert Zurer]

In his paper on Coding Standard found on

http://www.idesign.net/idesign/DesktopDefault.aspx

Juval Lowy discourages the use of the ternary conditional operator with no
specific reason given.

I can understand that complicated code would be much less readable using nested
operators, but aside from that is there another reason? -- something going on
under the hood perhaps which make it inadvisable to use?

Which one is better?

if(person != null)
{
return person.FirstName;
}
return null;

OR

return person != null ? person.FirstName : null;

Robert Zurer

 

[Guest]

There's nothing different under the hood. Some people suggest/prefer not
using the ternary op because it's meaning isn't that obvious, and it's
specific to the C-style languages (although I'm sure there's other languages
that have similar that I don't know about). Anyways I don't think there's
anything wrong with using it in simple cases like you show, but ugly, nested,
long usages get pretty messy pretty quick making code hard to read, maintain,
understand, etc.

One minor note on your example; some people suggest that a function should
have only one exit point, and I generally agree for finctions longer than a
couple lines. So, your if/else example might become:

object rv = null; // return value

if (person != null)
{
rv = person.FirstName;
}

return rv;

 

[Jon Shemitz]

Juval Lowy discourages the use of the ternary conditional operator with no
specific reason given.

He's not a fan of explanations. "Do it my way, whether you understand
it or not."

I can understand that complicated code would be much less readable using nested
operators, but aside from that is there another reason? -- something going on
under the hood perhaps which make it inadvisable to use?

No. It's just the same old "it can be abused, so it should be banned"
logic.

Which one is better?

if(person != null)
{
return person.FirstName;
}
return null;

OR

return person != null ? person.FirstName : null;

The second one, imho, makes it clear that we are returning a value,
here, and that that value depends on the state of the person
reference.

The first one - without even an "else" clause - makes the link between
"person == null" and "return null" much weaker and more indirect. It
takes a bit more thought to see the link, and it would be a bit easier
for careless maintenance to break the link entirely.

Imho, the ternary operator is just fine on the right hand side of an
assignment, or a return, or in a parameter expression.

It's not fine when a ternary operator is nested inside a larger
expression, with the POSSIBLE exception of something like

ThisString + (Counter != 1 ? "s" : "") + ThatString

 

[Robert Zurer]

One minor note on your example; some people suggest that a function should
have only one exit point, and I generally agree for finctions longer than a
couple lines. So, your if/else example might become:

object rv = null; // return value

if (person != null)
{
rv = person.FirstName;
}

return rv;

Thanks for your response. It confirms what I thought. With regard to the single
exit point, is this also for readabilty, or is there another reason?

Recently I have started to use the multiple exit point style because it does
away with having to read through a lot of conditional logic which won't get
called.

Robert Zurer

 

[Kevin R]

The ternary operator is very handy.
I use it quite a lot in my work, which involves low level programming
microcontrollers in C. Before I was used to seing it, its meaning was
not immediately obvious to me. but now, I am quite happy to use it.

I think once you are used to using it, its meaning becomes quite
obvious. As has been said though, keep it simple, don't starting
nesting one inside another. I think that if you can't keep it all on
one line, it may be an idea to use if/else instead

Kevin R

 

[James Curran]

The first one - without even an "else" clause - makes the link between
"person == null" and "return null" much weaker and more indirect. It
takes a bit more thought to see the link, and it would be a bit easier
for careless maintenance to break the link entirely.

No Problem. Just rewrite it:

if(person == null)
{
return null;
}
return person.FirstName;

Which makes the link you discuss far clearly that either fragments in the
OP.

 

[Bob Grommes]

Single exit points are a (misguided) attempt to keep method logic simpler.
It is a good example of "throwing out the baby with the bathwater".

Sometimes, multiple exit points make a method clearer, and sometimes they
make it hard to follow or easy to overlook alternate conditions. I don't
hesitate to use them, say, in a simple method that just needs to return a
value based on a switch statement, e.g.,

private string Fooness(string foo) {

switch (foo) {
case "bar":
return "WasBar";
case "foo":
return "WasFoo";
default:
return null;
}

}

It's perfectly self-evident what this is doing, more so (and probably more
efficiently) than artificially creating a return variable, setting that
variable in the switch, and then doing a return of the variable at the end
of the method.

I suppose you could argue that methods tend to grow in complexity over time
and then you could end up with 20 cases, some of them rather large, and then
the returns would be "buried" in all the "noise", and therefore, this is a
bad practice. However, in that case, you should generally refactor this
back down to a short, sweet, simple method anyway, and call other methods to
handle lengthy cases.

I tend to favor "single exit point" designs only when they simplify /
clarify the intent of the code.

--Bob