Monday, August 20th, 2007
Fun with ternary operators
<>p>Paul Bakaus wanted to save some bytes, and ended up geeking out on ternary operators and bitwise operations in JavaScript.Ready to write some code like this?
-
-
condition == true && ( foo() | bar() | some() );
-
-
function findActive(selector) {
-
return selector != undefined
-
? typeof selector == "number"
-
? headers.eq(selector)
-
: headers.not(headers.not(selector))
-
: selector === false
-
? jQuery("<div>")
-
: headers.eq(0)
-
}
-
Related Content:











I don’t hate future-me that much.
Please, please, start checking that a post doesn’t break a site when you post it.
I wonder if this trick could be employed in JavaScript compressors, that would be really cool. Dean Edwards (packer), Julien Lecomte (YUICompressor), what do you think?
damn that’s lame
1) it’s really hard to understand
2) it looks like one from TheDailyWTF
3) (foo()||bar()||some()) might be better for condition
No hire
Hi Developers of Ajaxian, today I have looked at your site, it has been messed up.
I cant see anything….. its all messed up…..
I think some where.. went wrong…..
Thanks,
Vivek
anonymous: “(foo()||bar()||some()) might be better for condition”
If “foo()” returns something truthy, “bar()” and “some()” will not be called. See http://en.wikipedia.org/wiki/Short-circuit_evaluation
Kevinin
Well you can do it also this way :-)
3 == (foo() + bar() + some());
I’m a big fan of the conditional (ternary) operator and similar tricks when they make the code simpler and easier to understand. But that findActive function is a mess. For one thing, it has dead code in it – the jQuery(“<div>”) call can never be reached. (To get there, both “selector == undefined” and “selector === false” would have to be true, and that can’t happen.)
If I understood what the code was supposed to do, I would see about writing it out in a simpler fashion. Be warned: it may still involve the conditional operator! :-)
Ack, I just checked the original source, and it looks like my good friend Jörn wrote that function. Don’t take offense, Jörn! I’ve written many functions that were a mess too… :-)
What the hell?
I don’t even get what it’s supposed to do
Im sure this is cool buried deep in some framework for optimization, but why are you posting it here ?
I was going to point out that you can write “condition == true && ( … )” as “condition && ( … )”, making both that and “else” (“condition || ( … )”) somewhat shorter, but it seems so obvious that I wonder whether there’s a reason you explicitly compare it to true. Is there?
@Tim: You’re absolutely right. There is no reason, I haven’t been thinking when writing down “condition == true”, it destroys boolean thinking. It should have been “condition” only, of course.
@all: Yes, I definitely agree after playing around with it more, it will not suit for most cases, and I definitely like to keep code readable (I have to, since many people are working on same code). I had fun playing around with the different methods, but I definitely do not advise to use all these hacks in your critical code.
Herzlichen Glückwunsch Paul!
Jetzt wirst Du doch ein mal namentlich hier genannt. ;)
Neat, and almost-readable due to the indentations. Still, I think I’d prefer “if” and “else”…