Link Details

This description is not 100% accurate. This article is about C# and never mentions C, C++, or Java.

This tip may work in other languages but the author never addresses that.

The ternary operator works the same in C/C++ and Java. If you replace the == with .equals() it works just fine in Java for example. However, it makes the code very hard to read for everyone who doesn't know that trick.

There are quite a few ideas for simulating String switches tho. E.g.:
http://www.xefer.com/2006/12/switchonstring

I'm always torn about the ternary operator....
It's rare enough (because it's purely syntactic sugar...) that many developers don't see it often, and hence will either:
* be completely lost when they run into it, or
* have to puzzle over it a bit to figure out what the result will be

And how often do you see them chained? Guaranteed, you'll stump a few junior programmers who are supposed to maintain this code (and they in turn will either screw it up, or waste the time of a higher-up developer asking for help). Sometimes, you have to use more complicated or unusual structures, but there's a cost.

Code is written to be read, so unless you're sure you're improving the readability enough to make it worth the cost, don't do it.

The chained ternary operators (like in the post) are even rarer, and with any even slightly complex logic they get messy pretty quickly. I've run into code using chained ternary operators where I was forced to rewrite the code before I could figure out what it was doing... it was just chains like that, but with complex, multi-part tests, and line breaks at random....

complete abuse of the ternary.
Seems like a Map (dictionary for c#'ers) or even an array would be better for this case.

Who is voting this up. chaining ternary, what a nightmare.

Voted it up because the construct was interesting... not because it's a good idea to do so (well, it clearly isn't).

I have to agree with the other downvoters here - chaining ternary statements isn't more clean, it's more clever - and harder for the average coder to read.

Although I don't think the ternary operator shouldn't be used to solve this specific problem I think it has its' uses like setting defaults ( value == null ? "not set" : value ) etc.

I have to admit I have never used a ternary operator like this, it is fun to see the controversy it has created. The reason I posted this, is because when I was developing my open-source .NET expression parser (LazyParser.NET), a chained ternary expression was one of the test cases I used to test the parser. It struck me as "interesting" to say the least...

On the other hand, in very specific cases, it is quite elegant to replace "if..else if ... " with a chained ternary operator. Isn't this what makes coding fun once in a while?

I don't think it's elegant - it's clever coding, which certainly has its appeal. I think others had the same reaction - they looked at it and thought, "Hey, I never thought of that!", but then thought, "Ohhhh. That might be hard to follow."

I have always liked the ternary operator myself and am constantly surprised at how many people don't like it. It has been around for a long time way before Java and .NET. Complex logic aside, why not chain it if it results in more elegant code that is easer to read?

It's only less clean and less readable to seriously inferior programmers. Perhaps such programmers should not be programmers at all?

What's worse... being inferior or being elitist?
An entry level programmer starting his/her first job is, by definition, inferior. Their peers should set a good example and write easily readable code. And not be put down because they're not as good as you.

Who said anything about putting them down? By all means, teach the apprentice. Verbosity != Clean and readable.

spread such constructs across 10000+ lines of code and anyone on the team will feel inferior till the end of days of the project.

simple things should be done the simple way
simple things are simple because we expect their behavior/structure before we have a closer look at them
don't express expectable behavior with unexpected (tricky) constructs
in the long run its frustrating to reverse engineer tricky code that expresses trivial concepts

You people are hilarious.

What a fuss over stupid article about a simple language feature that few people know about. The code sample I gave is not complicated, and cleaner than the if-then-else way of writing it, *IN THIS SPECIFIC CASE*. And in this case, even if someone doesn't have a clue about what the ternary operator does, he/she will still capture the meaning of that piece of code, because of the way it is written.

I would never recommend this pattern for performing complex conditional assignments. It's just a piece of code showing the "special" behavior of a right-associative operator such as the ternary operator.