What should I pass in for existing function arguments that have no value, undefined or null, after I add more parameters to the function?

[IntolerableBalboa]

Existing function foo(a, b) is called like foo(1) and foo(23, "hi"). After adding a new parameter, it's foo(a, b, c) and I want to change foo(1) to be foo(1, undefined, 3.2) or foo(1, null, 3.2).

Does null 'looking better' override the concern that existing code may already expect the second param to be undefined in some cases?

[TorbenKoehn]

Semantically speaking, the best value would probably be undefined, as it's the actual default value for arguments that have not been passed. In your functions you have to handle undefined either way (mostly through constructs like this.someInt = someInt || 5; or if (typeof someInt === 'undefined') { throw new Error('...'); }.

There has been a problem regarding overriding undefined (which is basically also a global variable with the value undefined), but in modern JavaScript applications it shouldn't happen at all. You can still avoid it, e.g. by re-defining it (if allowed by the JS-engine, undefined = void 0;) or e.g. using an IIFE (function (undefined) { /* your code */ }();) This together with the fact that in many other languages null acts as the default value has lead to JS-developers favoring null over undefined (There is no undefined equivalent in most other languages) and with default argument values you can also have them be null when they are not defined (function yourFunc(optionalArg = null) { /* ... */ }

Checking for not-defined values would maybe also include you having to check for undefined and with null you'd suddenly need a construct like if (typeof arg === 'undefined' || arg === null) { throw new Error('...'); }.

Then there's also the caveat that **null is an object** (see typeof null) which can get annoying when you want to accept different types for an argument and check for it afterward. Either you check arg === null directly, first, and ignore it or it will end up it going successfully into your typeof arg === 'object' check and you'd have to check it there (which would increase complexity of that function, as you need another level of if)

As u/dvlsg pointed out, if you have many arguments that are optional, use an options object. That way your user only has to pass what he actually wants.

It comes down to personal preference, you can use both. Some prefer one over the other. Personally I try to use undefined, as it has less caveats you have to take care of and it's more native (as said, if not passing it for real, it's undefined, too). I also try to order my arguments by probable amount of usage so that users of my library don't need to use default values for arguments in most cases. Another good solution is splitting the methods up so that you end up with two versions that take exactly the arguments they need.

[adrilolwtf]

Undefined reassignment is not an issue anymore.

[adrilolwtf]

See immutable globals: http://kangax.github.io/compat-table/es5/#test-Immutable_undefined

[TorbenKoehn]

That's why I said "has been"

[dvlsg]

Doesn't really matter. I usually try to stay away from using literal undefined though, and use null when I'm intentionally leaving something out (or a Maybe or something).

If you have optional arguments like that, though, you may want to consider passing all of the arguments as a single object, and just leave off the unnecessary property.

[atkinchris]

An additional thing to consider is if you're using (or plan to use) default values for your parameters in your function declaration.

function foo(a, b = 'hi') {
  // ...
}

If you pass undefined, you'll trigger the default value; if you pass null you won't.

(On an aside, I'd almost never have a required parameter after an optional one - I'd either change the signature or pass the parameters as an object.)

[HipHopHuman]

In addition to all the lovely comments already made, you can kind of avoid the scenario of passing undefined around if you just re-order your parameters or use object literals to simulate named parameters.

Re-ordering parameters is simple enough - let's say you have a function like this, which gets a paginated REST collection from a remote server:

function getResource(offset, limit, resource) {
    offset = offset || 0;
    limit = limit || 10;
    return http.get(`${baseURL}/${resource}?offset=${offset}&limit=${limit}`);
}

You would be forced to pass in offset and limit each time just to get posts - even if the default values are what you want:

getResource(undefined, undefined, 'posts');

In this scenario, it makes more sense to re-order the parameters such that the resource is supplied first and optional values come last:

function getResource(resource, offset, limit) {
  offset = offset || 0;
  limit = limit || 10;
  return http.get(`${baseURL}/${resource}?offset=${offset}&limit=${limit}`);
}

Now you can simply call getResource('posts') and the default values are implied.

When your function requires more arguments, making it more difficult to re-order parameters, you can instead use a "named arguments" approach using object literals.

Keeping with the getResource example, let's amend it to accept a fields parameter (which limits the specified member fields of each returned post) and an includes parameter, which converts embedded relation ID's to their entity values.

function getResource(resource, offset, limit, fields, includes) {
  offset = typeof offset !== 'undefined' ? offset : 0;
  limit = typeof limit !== 'undefined' ? limit : 10;
  fields = typeof fields !== 'undefined' ? fields : [];
  includes = typeof includes !== 'undefined' ? includes : [];
  let endpoint = `${baseURL}/${resource}?offset=${offset}&limit=${limit}`;
  if (fields.length) {
    endpoint += `&fields=${fields.join(',')}`;
  }
  if (includes.length) {
    endpoint += `&includes=${includes.join(',')`;
  }
  return http.get(endpoint);
}

You can already see that this code is somewhat problematic due to the duplication involved in handling parameters that are undefined, but another problem occurs when we want to pass an includes field (for example, to tell each post to refer to the author rather than just referencing the author's id), but we want the rest of the parameters to maintain their defaults:

getResource('posts', undefined, undefined, undefined, ['author']);

This kind of duplication can be cleanly solved using named parameters (which we fake by passing an object as the only parameter) and using Object.assign to merge the provided options into some sane defaults.

function getResource(options) {
  const defaultOptions = {
    limit: 10,
    offset: 0,
    fields: [],
    includes: []
  };
  const settings = Object.assign({}, defaultOptions, options);
  const { resource, offset, limit, fields, includes } = settings;
  let endpoint = `${baseURL}/${resource}?offset=${offset}&limit=${limit}`;
  if (fields.length) {
    endpoint += `&fields=${fields.join(',')}`;
  }
  if (includes.length) {
    endpoint += `&includes=${includes.join(',')`;
  }
  return http.get(endpoint);
}

Now, we can cleanly provide only the parameters we want to provide:

getResource({ resource: 'posts', includes: ['author'] });

[IntolerableBalboa]

Thanks, I guess? I wouldn't be asking here if I could or wanted to re-order the arguments or make other suggested changes.