4 ms·
for many cases the following will work well enough: function(arg1, arg2) { arg1 = arg1 || "foo"; arg2 = arg2 || "bar"; } it will fail of c
by leeoniya 14y ago
for many cases the following will work well enough:
function(arg1, arg2) {
arg1 = arg1 || "foo";
arg2 = arg2 || "bar";
}
it will fail of course if you expect to accept falsy args tho, then you need a bit moar kludge...
arg1 = arg1 !== 0 ? 1234 : arg1;
arg1 = arg1 !== false ? "foo" : arg1;
arg1 = arg1 !== null ? "foo" : arg1;
arg1 = arg1 !== "" ? "foo" : arg1;
and if you expect to accept multiple types of falsy values for any one argument (which requires a lot more kludge), you should probably change your API :)
- STRML 14y agoYou are correct, except this will not work in the significant case where any falsy value is passed ("", 0, null, NaN... I exclude undefined because that is the intended behavior) or with booleans. A slightly more verbose, yet hardy syntax would go like this: function foo(arg1, arg2){ arg1 = arg1 === undefined ? "foo" : arg1; arg2 = arg2 === undefined ? "bar" : arg2; } This would catch the intended behavior, which is to fill a parameter when it is not supplied at all.
- leeoniya 14y agoalready was updating :)
- yuchi 14y agoIf you don't mind, I need to correct the form a little. If this becomes a pattern in a big application you are losing performance for nothing. In fact you're just compacting an if: if (arg1 == null) { // check for both `undefined` and `null` arg1 = 'default'; } // compacted to: arg1 = arg1 == null ? 'default' : arg1; The difference is that you're always doing an assignement, even if unnecessary. (arg1 == null) && (arg1 = 'default');
- STRML 14y agoThe assignment is hardly a performance concern in modern javascript. I imagine if we set up a jsperf test case we would find the difference negligible and the ops/s in the 10s of millions range. This is not the kind of thing that slows down JS apps. I could see, using the if statement form, that you might have a programmer decide to compact it and drop the brackets - and then you might fall in the trap where somebody thinks they're in an if block when they're really not. Happens pretty often. In addition, I don't know if you really would want to check for null. I usually just check for undefined, which would be the absence of any provided value (as opposed to a provided value that just happens to be null). Of course, it depends on the app. In addition, I really don't like using short-circuited boolean ops for assignment. The style is grating to me - it's not immediately obvious what it's really doing. To each his own. EDIT: Created a simple jsperf test. Difference is about 6.8%, but we're talking hundreds of millions of ops/s. Not the kind of stuff that matters outside of raw benches. http://jsperf.com/ternary-vs-if-for-default-args http://jsperf.com/ternary-vs-if-for-default-args
- leeoniya 14y agoyou may have to check for null if you want to use a default arg2 while providing an explicit arg3. i guess you can always do: myfn('a',undefined,'b');
- STRML 14y agoYeah. You see that sometimes in modern JS, e.g. when pretty-printing JSON: JSON.parse(object, undefined, 2);
- yuchi 14y agoI'm not talking about single occurence of the "bad" pattern. If you multiple it to the occurence in a whole code base... well you get the point. That's why underscore and coffee-script treat default assignement that way.
- STRML 14y agoInterestingly, in JSPerf, sometimes the ternary pattern is actually faster than the if statement. Must be something V8 is doing.