How best to determine if an argument is not sent to the JavaScript function
Solution 1
There are several different ways to check if an argument was passed to a function. In addition to the two you mentioned in your (original) question - checking arguments.length
or using the ||
operator to provide default values - one can also explicitly check the arguments for undefined
via argument2 === undefined
or typeof argument2 === 'undefined'
if one is paranoid (see comments).
Using the ||
operator has become standard practice - all the cool kids do it - but be careful: The default value will be triggered if the argument evaluates to false
, which means it might actually be undefined
, null
, false
, 0
, ''
(or anything else for which Boolean(...)
returns false
).
So the question is when to use which check, as they all yield slightly different results.
Checking arguments.length
exhibits the 'most correct' behaviour, but it might not be feasible if there's more than one optional argument.
The test for undefined
is next 'best' - it only 'fails' if the function is explicitly called with an undefined
value, which in all likelyhood should be treated the same way as omitting the argument.
The use of the ||
operator might trigger usage of the default value even if a valid argument is provided. On the other hand, its behaviour might actually be desired.
To summarize: Only use it if you know what you're doing!
In my opinion, using ||
is also the way to go if there's more than one optional argument and one doesn't want to pass an object literal as a workaround for named parameters.
Another nice way to provide default values using arguments.length
is possible by falling through the labels of a switch statement:
function test(requiredArg, optionalArg1, optionalArg2, optionalArg3) {
switch(arguments.length) {
case 1: optionalArg1 = 'default1';
case 2: optionalArg2 = 'default2';
case 3: optionalArg3 = 'default3';
case 4: break;
default: throw new Error('illegal argument count')
}
// do stuff
}
This has the downside that the programmer's intention is not (visually) obvious and uses 'magic numbers'; it is therefore possibly error prone.
Solution 2
If you are using jQuery, one option that is nice (especially for complicated situations) is to use jQuery's extend method.
function foo(options) {
default_options = {
timeout : 1000,
callback : function(){},
some_number : 50,
some_text : "hello world"
};
options = $.extend({}, default_options, options);
}
If you call the function then like this:
foo({timeout : 500});
The options variable would then be:
{
timeout : 500,
callback : function(){},
some_number : 50,
some_text : "hello world"
};
Solution 3
This is one of the few cases where I find the test:
if(! argument2) {
}
works quite nicely and carries the correct implication syntactically.
(With the simultaneous restriction that I wouldn't allow a legitimate null value for argument2
which has some other meaning; but that would be really confusing.)
EDIT:
This is a really good example of a stylistic difference between loosely-typed and strongly-typed languages; and a stylistic option that javascript affords in spades.
My personal preference (with no criticism meant for other preferences) is minimalism. The less the code has to say, as long as I'm consistent and concise, the less someone else has to comprehend to correctly infer my meaning.
One implication of that preference is that I don't want to - don't find it useful to - pile up a bunch of type-dependency tests. Instead, I try to make the code mean what it looks like it means; and test only for what I really will need to test for.
One of the aggravations I find in some other peoples' code is needing to figure out whether or not they expect, in the larger context, to actually run into the cases they are testing for. Or if they are trying to test for everything possible, on the chance that they don't anticipate the context completely enough. Which means I end up needing to track them down exhaustively in both directions before I can confidently refactor or modify anything. I figure that there's a good chance they might have put those various tests in place because they foresaw circumstances where they would be needed (and which usually aren't apparent to me).
(I consider that a serious downside in the way these folks use dynamic languages. Too often people don't want to give up all the static tests, and end up faking it.)
I've seen this most glaringly in comparing comprehensive ActionScript 3 code with elegant javascript code. The AS3 can be 3 or 4 times the bulk of the js, and the reliability I suspect is at least no better, just because of the number (3-4X) of coding decisions that were made.
As you say, Shog9, YMMV. :D
Solution 4
In ES6 (ES2015) you can use Default parameters
function Test(arg1 = 'Hello', arg2 = 'World!'){
alert(arg1 + ' ' +arg2);
}
Test('Hello', 'World!'); // Hello World!
Test('Hello'); // Hello World!
Test(); // Hello World!
Solution 5
There are significant differences. Let's set up some test cases:
var unused; // value will be undefined
Test("test1", "some value");
Test("test2");
Test("test3", unused);
Test("test4", null);
Test("test5", 0);
Test("test6", "");
With the first method you describe, only the second test will use the default value. The second method will default all but the first (as JS will convert undefined
, null
, 0
, and ""
into the boolean false
. And if you were to use Tom's method, only the fourth test will use the default!
Which method you choose really depends on your intended behavior. If values other than undefined
are allowable for argument2
, then you'll probably want some variation on the first; if a non-zero, non-null, non-empty value is desired, then the second method is ideal - indeed, it is often used to quickly eliminate such a wide range of values from consideration.
Related videos on Youtube
penetra
I am a website and web application developer in Calgary, Alberta. I have been doing backend web development in PHP and frontend in HTML/CSS/JavaScript for over 20 years. My specialties are Symfony, Vue, Event Sourcing & CQRS, Craft CMS, WordPress. I've built everything from basic basic brochure style websites to heavily trafficked eCommerce site and social platforms to internal applications.
Updated on September 03, 2021Comments
-
penetra almost 3 years
I have now seen 2 methods for determining if an argument has been passed to a JavaScript function. I'm wondering if one method is better than the other or if one is just bad to use?
function Test(argument1, argument2) { if (Test.arguments.length == 1) argument2 = 'blah'; alert(argument2); } Test('test');
Or
function Test(argument1, argument2) { argument2 = argument2 || 'blah'; alert(argument2); } Test('test');
As far as I can tell, they both result in the same thing, but I've only used the first one before in production.
Another Option as mentioned by Tom:
function Test(argument1, argument2) { if(argument2 === null) { argument2 = 'blah'; } alert(argument2); }
As per Juan's comment, it would be better to change Tom's suggestion to:
function Test(argument1, argument2) { if(argument2 === undefined) { argument2 = 'blah'; } alert(argument2); }
-
Luca Matteis over 15 yearsIt's really the same. If you always have a static number of arguments then go with the second method, otherwise it's probably easier to iterate using the arguments array.
-
Ruan Mendes over 13 yearsAn argument that was not passed comes in as undefined. Testing with strict equality against null will fail. You should use strict equality with undefined.
-
Sandy Gifford about 11 yearsRemember:
argument2 || 'blah';
will result in 'blah' ifargument2
isfalse
(!), not simply if it is undefined. Ifargument2
is a boolean, and the function is passedfalse
for it, that line will return 'blah' despiteargument2
being properly defined. -
rvighne about 10 years@SandyGifford: Same problem if
argument2
is0
,''
, ornull
. -
Sandy Gifford about 10 years@rvighne Very true. Javascript's unique interpretation of objects and casting is all at once it's best and worst parts.
-
-
Christoph over 15 yearsAnd Tom got two upvotes for a wrong answer - it's always nice to know how good these community systems work ;)
-
Christoph over 15 yearsif(!argument2) argument2 = 'default' is equivalent to argument2 = argument2 || 'default' - I find the second version visually more pleasing...
-
dkretz over 15 yearsAnd I find it more verbose and distracting; but it's personal preference, I'm sure.
-
Shog9 over 15 years@le dorfier: it also precludes the use of empty strings, 0, and boolean false.
-
Shog9 over 15 years@le dorfier: beyond aesthetics, there's one key difference: the latter effectively creates a second path of execution, which might tempt careless maintainers to add behavior beyond the simple assignment of a default value. YMMV, of course.
-
JW. over 15 yearsYou should actually check typeof argument2 === "undefined", in case someone defines "undefined".
-
Christoph over 15 yearsI'll add a notice - but what sick bastards do things like that?
-
JW. over 15 yearsNobody that I know, so I usually use === undefined. But someone pointed out to me (on a similar thread) that undefined isn't actually a JavaScript keyword, so this is kind of a hack.
-
some over 15 yearsundefined is a variable in the global space. It is slower to lookup that variable in the global scope than a variable in a local scope. But the fastest is to use typeof x === "undefined"
-
Christoph over 15 yearsInteresting. On the other hand, the comparison === undefined might be faster than the string comparison. My tests seem to indicate that you're right, though: x === undefined needed ~1.5x the time of typeof x === 'undefined'
-
Ruan Mendes over 13 yearsThat is because strings in JavaScript are immutable, so string comparison is just testing pointers, not testing content.
-
Christoph over 13 years@Juan: immutable strings don't imply unique strings, and only the latter would mean equivalence of string equality and pointer equality; take the Java VM as an example for a language runtime with immutable, but - in the general case - non-unique strings
-
Ruan Mendes over 13 years@Cristoph, that is very interesting. I always assumed immutable strings would go along with unique strings. Why would you create two objects with the same contents if they can't be changed?
-
Christoph over 13 years@Juan: unique strings penalise string creation - if a string's contents aren't known at compile-time, you'll have to hit a string cache (some kind of hashtable or search tree) at runtime to guarantee that you don't create a duplicate; afaik even if they don't use unique strings, many string handling frameworks choose immutability over alternatives like copy-on-write for various reasons (simpler algorithms, easier memory management, ...)
-
Ruan Mendes over 13 years@Cristoph: after reading your comment, I asked around. I was able to prove that string comparison is surely not (only) by pointer comparison since comparing a gigantic string takes longer than a small string. However, comparing two gigantic strings is really slow only if they were built up with concatenation, but really fast if the second one was created as an assignment from the the first. So it probably works by a pointer test followed by letter by letter testing So, yeah, I was full of crap :) thanks for enlightening me...
-
Cmag over 9 yearsfolks, what if the function's last parameter is a callback()?
-
rosell.dk almost 8 yearsDoes not work with boolean true, zero and empty string. For example, foo(0); will log false, but foo(1) will log true
-
rosell.dk almost 8 yearsinstead of writing the keyword "undefined", you can write "void 0". This saves a couple of characters. Google Closure Compiler uses that trick. Ie: (undefined===argument2) can be rewritten to (void 0===argument2)
-
rosell.dk almost 8 yearsIf you are going to use that function twice, the least-characters-solution is this to deligate it to a helper: function u(a){return void 0===a}.
-
fresko over 7 yearswhat if parameter2 is a boolean === false; or a function {return false;} ?
-
Paul Rooney over 7 yearsBare bones answer. Some explanation wouldn't hurt.
-
Ulysse BN almost 7 yearsThis answer is really interesting and could be useful to op. Though it doesn't really answers the question
-
andriy2 almost 7 yearsAs I see - he wants to define arg if it was not defined, so I posted some helpful information
-
Ulysse BN almost 7 yearsMy point is you're not answering to How best to determine if an argument is not sent to the JavaScript function. But the question could be answered using default arguments: for instance naming you arguments with
"default value"
and checking if the value is indeed"default value"
. -
Charles Wood over 6 yearsThis actually means "if
value
is equivalent tofalse
, set it to 0." This is a subtle but very important distinction. -
Zameer Ansari over 6 years@CharlesWood Value not passed / present means is false only
-
Charles Wood over 6 yearsSure, if that fits the requirement for your function. But if, for example, your parameter is boolean, then
true
andfalse
are valid values, and you may want to have a third behavior for when the parameter is not passed at all (especially if the function has more than one parameter). -
Charles Wood over 6 yearsAnd I should acknowledge that this is a huge argument in computer science and may just end up being a matter of opinion :D
-
Zameer Ansari over 6 years@CharlesWood sorry for being late to the party. I suggest you to add these in the answer itself with edit option
-
Bronzdragon over 5 yearsEven if you pass a callback, @fresko, that callback would equate to true, since it's a function. The function wouldn't be called, so it doesn't return a falsey value.
-
rmooney almost 5 yearsIt's a ternary operator that concisely says: If url is undefined (missing), set the url variable to be location.href (the current web page), otherwise set the url variable to be the defined url.
-
Apostolos over 3 yearsThis is by far the best answer! And with a full stop! (I really wonder why all this fuss (including the long comment that accompanies it! :))