ternary op

[alessioalex]

I'm sorry but Ruby is a programming language aimed for humans to understand, right?

So if I ask a journalist to tell me what this is what would he say:
result = some_condition ? something : something_else

How about when I ask him to interpret this:
result = if some_condition then something else something_else end

This rule doesn't make sense, you should interchange the "good" with the "bad".

[bbatsov]

The rules where actually reversed initially, but due to the overwhelming opinion that use of the ternary operator is favored by most Ruby devs and that it is fairly readable (not to mention concise) the original advice was inversed.

[alessioalex]

It's not readable it's just shorter. At least remove this coding guideline.

It looks more like C code or regex to a newcomer imo.

[wersimmon]

I agree with @alessioalex, with the further caveat that short "do this if/unless" should be written that way: do_things if something. Ternary operators can be more confusing given Ruby's allowance of ! and ? in method names.

# Hard for me to read.
Thing.has_things? ? foo : bar

# Easy for me to read.
if Thing.has_things? then foo else bar end

[alessioalex]

This is really debatable, and I sometimes used the ternary operator (in PHP), but I think it's not as "beautiful" as the rest of the Ruby code. I don't think it belongs with the rest of the code.

Other opinions on the Internet:

http://ruby.about.com/od/beginningruby/a/The-Ternary-Or-Conditional-Operator.htm
"It has its uses, but it's also a bit controversial."

http://ruby.railstutorial.org/chapters/sign-in-sign-out
"This code uses the strange but useful ternary operator to compress an if-else construction into one line"

Douglas Crackford (JavaScript authority): "I prefer not using the ternary operator."

[bbatsov]

I'd like you to factor #26 in the discussion. It's no secret what my preference on the matter is, but this is a community effort :-)

[alessioalex]

Pro ternary:

mkorfmann
ralph
DAddYE

More readable if then else:

bbatsov
alessioalex
echoback

Since it's 50-50%, should the shorter (more concise, but less readable) version even be a standard?
I think the simplest thing is to just remove this from the standards.

Just search google for people that don't know what a ternary operator is :) You'd be surprised.

[DAddYE]

The answer is simple, there is no code with long version of ternary op.

Then I think become unreadable in this example:

x = check_this(if Thing.respond_to?(:foo) then foo else bar end)

who has seen this code?

much better and more coding standard this:

x = check_this(Thing.respond_to?(:foo) ? foo : bar)

[alessioalex]

Sorry but.. my opinion is that it's completely the other way around.
The following look really really ugly code to me:

x = check_this(Thing.respond_to?(:foo) ? foo : bar)

This look ugly too, yet a little better:

x = check_this(if Thing.respond_to?(:foo) then foo else bar end)

However I wouldn't use either.

I'm just saying, as a newcomer to the language and in Ruby's spirit (beautiful code, as DHH said), should the ternary operator be a best practice?

I mean we could make a function "focba" instead of "find_or_create_by_attributes", that would be shorter, but ugly and not suggestive. To me, the ternary operator would be somehow similar.

I had no idea what the ternary operator did the first time I saw it, I had to search google.

[wersimmon]

How about a compromise, centered on argument lists? if/then/else for conditions outside of the arguments, ternary for conditions inside the arguments. Like so:

# Outside
name = if animal.is_pet? then animal.name else animal.species end

# Inside
animals.find_by_type(animal.respond_to?(:sit) ? 'dog' : 'cat')

I think this gives a pretty decent amount of readability to each. Ternary operators make sense in that situation.

[ghost]

Just look at the usage numbers of both here: #26 . Almost nobody uses if/then/else/end. Dude we're programmers, no "journalist" will look at ruby code and no buisness person either. So let's save some keystrokes and get things done :).

[philtr]

Just because nobody uses it doesn't mean it's bad. I'd like to see an argument for the use of the ternary operator that doesn't involve usage in current code. That is, the argument should be why everyone uses the ternary operator instead of just that everyone does.

I don't know where I stand in this debate. I love the conciseness of the ternary operator, but I have to agree that if/then/else/end is a great deal more readable.

And as far as business people coding, what about Everybody Codes?

Not taking sides here, I just think that we should consider why we do things instead of doing them.

[trliner]

I support keeping the ternary operator in the style guide because after seeing it used in hundred of lines of Ruby code, when I come across

predicate ? consequent : alternative

I immediately recognize the boundary between each clause of the statement, and I can quickly scan to the clause I'm interested in. Whereas, when I glance at

if predicate then consequent else alternative end

the words run together, and I can't easily tell where one clause ends and another clause starts.

[getconor]

According to Matz, "Ruby is designed to make programmers happy." Not, as alessioalex said, "a programming language aimed for humans to understand". There are many other programming languages that were designed to be understood by non-programmers, and they are not as terse, not as powerful per line, and I don't know of any that have methods, or even concepts, like instance_eval. Should we recommend against instance_eval also? As far as a language for programmers, as David Heinemeier Hansson has said, he was drawn to Ruby by 1) the power the language gains from its inherent terseness, and 2) the beauty of the code. He has also said that he has had many people over the years tell him those are also the two features that drew them to the language.

A Ruby style guide should recommend best practices so that real-world Ruby programmers can write code that can be maintained by other real-world Ruby programmers. The fact is that, like it or not, people using the style guide will have to use the ternary operator if they are going to contribute to projects in the wider community, where the ternary operator is the accepted style and is vastly more popular than the if-then-else-end construction for use on a single line . My opinion is that since it is in such wide use in the community, then the style guide should cover the best way to use the ternary operator to make it more readable, instead of ignoring it altogether or recommending against its use and ignoring the widespread adoption in the community. In general, any style guide that ignores a feature in widespread use, or, worse, recommends against it after it has been accepted as the preferred option by the wider community, does nothing to minimize the use of the feature in question, but, instead, calls into question the style guide itself. Put another way, a style guide that reflects real world usage gets used, and a style guide that holds to an ideal that has been rejected by the people it is supposed to help risks not getting used at all, no matter how good it is.

[lyleunderwood]

@mhutchin I concur. If there's not one obviously preferable path to take, then saying "this is how to use each of the options correctly" seems like the best course of action.

[philtr]

I'm sold.

[benhamill]

My opinion is just like @trliner. The ? and ; are much better scan-interrupters than the words. If I felt like a ternary operator wasn't readable for a given instance, I would go to a full if/else statement across 5 lines or whatever.