• Frist (unregistered)

    var frist = isFrist == true ? true : false

  • Garreth Q. (unregistered)

    I am frist. Frist was zreoth.

  • Appalled (unregistered)

    If I have the time or the changes I'm making actually involve the ternary structure, I immediately "refactor" it into an If then else. Yes 4 lines rather than 1 but legible at a glance rather decompiling it in my human memory every time I have to look at it. I do this routinely and constantly. Ternaries should be outlawed.

  • Foo AKA Fooo (unregistered) in reply to Appalled

    Funnily, it's the opposite to me, in some cases. To me "foo = cond ? bar : baz" reads much easier than the equivalent if/else construct which I have to mentally compile into a single assignment. When looking at the code from a high-level view, with the ternary I see immediately that foo is assigned in any case, whereas with the if-else I'm like, ok if cond is true, then,well, foo is assigned, otherwise, oh, foo is assigned too, so foo is assigned anyway. (And when I need to look more closely, it doesn't matter much since I have to read and understand it all either way and the total complexity is about the same.)

    If-else may be easier when trying to mentally execute a single case (with a given cond value), but when trying to really understand the code (i.e., its behaviour for any input), the ternary is easier, even more so with a more complicated expression on the LHS such as "foo[i].x = ..."; with if-else I additionally have to check carefully that the else-branch really assigns to the same one and not perhaps to "fo0[i].x" or "foo[j].x" or "foo[i].y" etc.

    Another benefit (when applicable) is that the ternary requires an "else" clause. With a series of if-else-if-else you can accidentally forget the final else, leaving an unset value. A series of ternaries makes this impossible, so I'd prefer them unless I actually want to omit it (in which case "if" is justified because you really only want to assign under some conditions).

  • Ulysses (unregistered) in reply to Foo AKA Fooo

    +1. What's to 'decompile' anyway? Pfft, smh.

  • thosrtanner (unregistered) in reply to Foo AKA Fooo

    My favourite avoidance of ternary operators seen recently

    if ((cond1 && cond2) || (! cond1 && cond3))

    How much staring at that to realise what is meant to happen, as opposed to

    if (cond1 ? cond2 : cond3)

    I cant remember the whole context of the code so I'm not sure that was the best way to do things anyway, but at least the 2nd is readable

  • Zenith (unregistered) in reply to Appalled

    When ternaries are outlawed, only outlaws will have ternaries.

    I was going to say TRWTF was that top 4 had exactly the same effect as the bottom 4 but "I can't understand 1 line so everybody else should suffer through 5-7" is TRWTF.

  • Zenith (unregistered)

    Should've been "suffer through 4-8"...that comment triggered an off-by-one bug in my brain...

  • Randal L. Schwartz (google)

    My favorite antipattern is shell people wrongly using

    foo && if_foo_true || if_foo_false

    which works only if you can guarantee that if_foo_true always returns true. And then, it doesn't. And things break.

  • CE (unregistered)

    Tern around... Every now and then I get a little bit confused At this mess of conditions

    Tern around... Every now and then I feel a little regret That I didn't leave this job

  • Jeremy Hannon (google)

    The one time I find ternaries very useful is in property initialization scenarios such as creating an object using with {}. Often it is cleaner to just to do if statements after the fact, though. If you are doing it in a LINQ expression, though, ternaries are a must and save a lot of code writing since you are dealing with creating a collection of objects rather than a single one. Doing it after the fact makes it harder to read and makes it so you have to iterate over the collection again to do so.

  • MKA (unregistered)

    That first series of ternaries wouldn't be too bad as a starting point for a mapping that fixes up nullvalues, would it?

  • Sidney (unregistered) in reply to thosrtanner

    Good lord it burns my eyes. If I ever see a ternary in an if during code review I'm gonna fire someone. That is terrifyingly dense.

  • Ulysses (unregistered) in reply to Sidney

    Get real please.

  • Foo AKA Fooo (unregistered) in reply to Ulysses

    Yeah, I think he's a complex (double pun intended).

  • Lerch98 (unregistered)

    Abuse of ternary operator is Amateur hour. We have a guy at work that is learning C language (or so he thinks) and he got stuck up on some stupid nested ternary anti pattern that was 4 levels deep and he was so proud of himself. I told him if he wants a job writing code to grow up and forget the stupid stuff like this. I tried to explain to him that the proper use of a ternary is something like this;

    int numof = (myArray == null) ? 0 : myArray.length() ; // I'm a Java nerd.

    I said; "Just because you can write a whole program in a ternary is no reason to do it, and proves you are just a (rank) amateur." Needless to say, He didn't listen, he still can not get his program to work correctly, and he lost out on a programming job.

  • poniponiponi (unregistered)

    Eh, fuck all y'all; ternaries are great. Spending six lines doing a simple if-then-else isn't helping readability, because nothing harms readability more than needing to constantly scroll to sections of code which are now too far away to fit on the screen.

  • (nodebb)
        return (!res != true ? !false : !true);  //challenge result
  • Izhido (unregistered)

    You know what would be nice? Somebody showing an example where using a ternary operator would make the code more readable than the alternative...

  • Matt Westwood (unregistered) in reply to Izhido

    Foo AKA Foo gave one in his comment, 2nd para down: when the target of the assignment is a complex variable e.g. a pointer assignment or an indexed element of an array, where you really don't want to have to repeat it: once in the if and once in the else.

  • Foo AKA Fooo (unregistered)

    thosrtanner gave another clear one. (And frankly, even a simple one, as in my first paragraph, is more readable to me this way.)

  • Insanity Check (unregistered)

    I think I might guess what the intention behind the first WTF was: Of course this.worldUuid = builder.worldId == null ? null : builder.worldId; is utter insanity, but this.worldUuid = (builder ? builder.worldId : null); stops you from derefencing builder when it is null. (This does not touch upon the subject if this is the right way to handle builder being null, if worldUuid being null makes any sense, the pro and cons of using ternaries or if/else, etc...)

  • dlareg (unregistered) in reply to Matt Westwood

    If cond == True: scratch = 8 else: scratch = 7 Foo[i].x = scratch

    Ofcourse you should give scratch, cond amd foo reasonable names

  • Foo AKA Fooo (unregistered) in reply to dlareg

    So now you introduce yet another line, and a temporary variable (that one has to keep track of mentally, including checking its scope, and whether it's used anywhere else, when trying to understand the code), for the sake of READABILITY!?!?!?

  • Hans (unregistered)

    boolean someFunction() { if (someBooleanExpression) { return true; } else { return false; } }

    is clearly wrong! ïf somebooleanExpression what??

    boolean someFunction() { if (someBooleanExpression == true) { return true; } else { return false; } }

    There! Much better!

  • rdwells (unregistered) in reply to Appalled

    (1) Like them or not, ternaries are part of the language. Deal with it and learn to read them. (2) Anyone on my team caught making such gratuitous changes to the source code might be given a second chance. They certainly would not be given a third.

  • Zenith (unregistered) in reply to rdwells

    I wonder how some of the people shouting "readability!1" ever made it through a high school English class. Did they just refuse to read books that weren't written at their literacy level because they were "unreadable?"

  • Frist yourself (unregistered) in reply to Frist

    I can't stand obfuscoders! I work with them.

  • Hernâni (unregistered)

    I don't see any problem using ternary operators. Their bad usage is the key problem.

    If is "readability" what we are talking about, why not just use...

    "return boolVar;" instead of "return (boolVar == true ? true : false);" ?

    It's quite dumb to create a ternary expression when we can use the own expression as source of evaluation.

  • Derek (unregistered)

    We have a strange error coding that makse 1 = successful and 2 as a failure. Not sure who did this, but we aren't changing it now. So here is something we have in our code:

    int errorCode = booleanresult ? 1 : 2;

    Simple, and exactly how a ternary operator should be used. Anything more complicated should use an if / else, but people who cannot find this readable should take up a new line of work.

Leave a comment on “Best of 2016: Tern Around…”

Log In or post as a guest

Replying to comment #:

« Return to Article