- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
var frist = isFrist == true ? true : false
Admin
I am frist. Frist was zreoth.
Admin
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.
Admin
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).
Admin
+1. What's to 'decompile' anyway? Pfft, smh.
Admin
My favourite avoidance of ternary operators seen recently
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
Admin
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.
Admin
Should've been "suffer through 4-8"...that comment triggered an off-by-one bug in my brain...
Admin
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.
Admin
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
Admin
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.
Admin
That first series of ternaries wouldn't be too bad as a starting point for a mapping that fixes up nullvalues, would it?
Admin
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.
Admin
Get real please.
Admin
Yeah, I think he's a complex (double pun intended).
Admin
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.
Admin
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.
Admin
Admin
You know what would be nice? Somebody showing an example where using a ternary operator would make the code more readable than the alternative...
Admin
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.
Admin
thosrtanner gave another clear one. (And frankly, even a simple one, as in my first paragraph, is more readable to me this way.)
Admin
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...)
Admin
If cond == True: scratch = 8 else: scratch = 7 Foo[i].x = scratch
Ofcourse you should give scratch, cond amd foo reasonable names
Admin
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!?!?!?
Admin
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!
Admin
(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.
Admin
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?"
Admin
I can't stand obfuscoders! I work with them.
Admin
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.
Admin
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.