I would say it is a matter of personal preference. However, first and foremost whichever thing you prefer should be codified in your project's style guide. Consistency trumps everything else by a large margin.

My personal opinion is that this is an excellent use of the ternary operator. When writing software, you want your code to be as simple and short as possible provided it is readable[1]. I find both of them to be equally readable, therefore I prefer the shorter one by a lot. We are talking about 5 lines of code vs 1, which can really add up if this appears commonly all over your codebase. One limited asset every engineer has is monitor real estate, and the more code you can fit on your screen, the better (provided all of that code is the readable variety).

I also find in this particular example, the ternary could get a slight nod for readability as well. This is because with the ternary operator, you start with:

value =

Ok, value is getting assigned to something... then you read the ternary expression. If you are grepping through this code and looking to see what value might be set to, you get to this line and you know you have found it, then you parse the rest of it to figure out what it is being set to.

With the other example, your grepping will lead you to a "value =" that is within a conditional, so now you have to look up and down and explore a little more to see what it might be set to. This is because the ternary operator can only do one small thing, whereas the if statement can do lots of things. Since you are only doing the simple thing, using the simplest possible operator to do that in some sense helps future people reading the code [2].

[1] Which might seem like a spectrum, but I think of it as much more binary. Code is either readable or it isn't. This might seem strange, but my fellow engineers and I spend quite a bit of time grading code submissions to our programming challenges, and of course the "readability" of the code is a key thing we grade for. I think we probably match up our independent up or down votes on readability at least 90% of the time.

[2] If you want to frustrate experienced engineers, have them look through a bunch of code that hasn't been factored down to its simplest form. This is extremely common among inexperienced engineers who refactor code and don't delete a bunch of cruft that now exists due to code or logic changes because "who cares? the code works!", and you get stuff like this:

  if ($has_phone_number) {
      return TRUE;
  } else if ($has_phone_number || $has_email_address) {
      return TRUE;
  } else if (!$has_phone_number) {
      return FALSE;
  } else {
      return FALSE;
  }

  return FALSE;

ahhhh!

$ git diff --stat

1 file changed, 1 insertions(+), 10 deletions(-)

I too would also like to know this. At first the ternary operator seems difficult to comprehend but after a little bit of mucking around with it it really seems more natural to me. When I'm thinking about a binary question rarely do I ever utter if/else in my internal monologue. I ask myself the question and the response is either a yes or a no.

since you asked for my opinion, i think that ? : syntax is a failure. languages where everything is an expression (usually functional languages) have a much better implementation:

    value = if (test) {some_value * multiple} else {false_value}

How is this "much better"? Once you understand the syntax of the ternary operator it's easy to read and easy to use.

Actually, it is much worse. Extra symbols certainly contribute to clutter and reduce readability.

More to that, in my opinion, "code flow" in functional languages is completely broken.

I have to remind myself how to read it every time I encounter it, and C and C++ are my dominant languages.

Better yet, you can do stuff like

  value = if (test) {some_value * multiple}
          else if (test2) {second_value}
          else {false_value}

which falls in a straightforward way out of the if/else syntax, which the language authors have put a lot more thought into than the rarely used ?: syntax.

How about formatting the ternary thusly:

  value = test
    ? (some_value * multiple)
    : false_value;

To match, it would have to be:

  value = test ? some_value * multiple
          : test2 ? second_value
          : false_value;

Which, you know, isn't that bad. But it looks really weird since people don't expect you to use ternary that way, while multi-part if statements are fairly normal.

That's basically the same syntax but with keywords. How is it 'much better'? And if you're doing something complex like nested ternary (please don't) you can use () to mark sections just as well as your method uses {} to mark sections.

it's better because 1) it falls out of the regular semantics of the language. it's just a regular if expression. it's a consequence of a more elegant and unified design, in other words. that ternary syntax by comparison is ad-hoc. to begin with, it's the only ternary operator in those kinds of languages. (thus people call it "the" ternary operator). it shows poor design restraint, imo

2) it's not punctuation. a ternary expression is a 3-input mapping to begin with. punctuation only makes it noisier.

>nested ternary (please don't)

Eh, if you use whitespace effectively it is perfectly readable. Moreso than the alternative, IMO.

Yep. My thinking exactly. Easiest thing to read is a table. Always :)

A table is fine, but the equivalent of 'else if' isn't true nesting. I meant making an elaborate tree, which should not be squished into a single statement unless you have a really good way of organizing it.

That's what I meant, as well :-)

Assuming I know the ternary operator, I find the first version superior. Why? It only says "value = " once. I know immediately what the action of the code is when I start reading. Starting with an if makes me worry that the two code paths diverge, and also makes it take analysis to realize that 'value' is definitely assigned.

From my personal perspective, readability comes from the "beauty" of the code. Humans instinctively go on their first impressions, so code that looks appealing at first glance is code that is desired to be worked on. The absolute readability difference between the ternary operator and an if statement is inconsequential outside of which better fits the design context, I think.

I always like to think the text editor is my canvas and the characters are my brush. My job is to make something functional, of course, but also something that looks beautiful.

This is actually one of the things that's driving Mike's research. When the latest programming paradigm comes out, usually people argue it's better based on the code being shorter or prettier. Judging programming styles based on beauty is inherently subjective, so Mike is trying to find some quantitative basis for comparing programming systems.