0

Is it usually recommended to define default values for Boolean arguments?

I mean, is it usually recommended to define a function like this

someFunction(a, b, x) {
   // a and b are strings, x is true or false
   ...
}

or like this?

someFunction(a, b, x = false) {
   // a and b are strings, x is true or false
   ...
}

In either case, the function can be called without x:

someFunction(a, b);
2
  • 2
    Does this answer your question: Default values - are they good or evil?
    – Doc Brown
    Apr 12 at 9:59
  • @DocBrown I would say my question is slightly different. It's not about a general case of using default values, but about specifying a default false value which is - in JavaScript - essentially optional. I do understand that this is very subjective and a matter of coding style, but I haven't found any mention of this case in style guides in which I looked for it.
    – jsv
    Apr 12 at 10:02
5

Javascript is somewhat different in this regard as it's very loose about it type and method definitions, and it fills in a lot of the gaps for you.

In this particular case, the two are completely equivalent. But this relies on two key notions:

  • Javascript doesn't care about missing method parameters to begin with.
  • You are setting the default value of the method parameter to the default value of a boolean (i.e. false)

If you change either of these notions, it ceases to be equivalent. Below are two examples of this.

However, before we get to the examples, I want to address your question:

Is it usually recommended to define default values for Boolean arguments?

Recommendations are not always done for technical benefit. It could be of a documentative nature.

For example, while the behavior between your two methods is exactly the same, if I were to start using your code, I would infer that someFunction(a, b, x) isn't intended to be called with missing parameters, whereas if I see someFunction(a, b, x = false), I can infer that whoever designed this method specifically expected that the third parameter might be omitted.

That doesn't change how the code works, but it does change my understanding of the author's intention when designing this method, so it changes how I develop this code further (e.g. not going round and "fixing" all method calls which seem to have "forgotten" the third parameter).

So is it recommended? Well, that depends.

  • As a blanket rule? No, that's silly.
  • As a way to indicate that omitting this parameter in this method is expected and not a problem? Yes, that's a great way of communicating that to future readers of your code.
  • As a way to actually change how the code behaves? Well, yes, but in your particular example, it doesn't quite matter since any uninitialized boolean will already be false anyway.

Example 1

For example, if you want x to be true by default. Compare these examples:

someFunctionWithoutOptionalValue(a, b, x)      { console.log(x == true); }  
someFunctionWithOptionalFalse(a, b, x = false) { console.log(x == true); }
someFunctionWithOptionalTrue(a, b, x = true)   { console.log(x == true); }

And we run this script:

someFunctionWithoutOptionalValue(a,b);
someFunctionWithOptionalFalse(a,b);
someFunctionWithOptionalTrue(a,b);

You will notice the following output:

false
false
true

When you define your optional value to be different from what the default value already is, then this makes a change to how the code behaves.


Example 2

While this may be less relevant for you now, if we move to another language which is much stricter with its typing but also has optional parameter values (I pick C# here), then the two examples you gave also are no longer equivalent.

public void SomeFunction(int a, int b, bool x) {}
public void SomeFunctionWithOptional(int a, int b, bool x = false) { }

I'm allowed to do either of these:

SomeFunctionWithOptional(1, 2, true);  // x will be true
SomeFunctionWithOptional(1, 2);        // x will be false

And I'm allowed to call:

SomeFunction(1,2,true);                // x will be true

But I am not allowed to omit a non-optional parameter:

SomeFunction(1,2);                     // COMPILER ERROR

In strongly typed languages, you must mention that a method parameter is optional before you are allowed to actually leave it empty when calling the method.

3
  • Thanks a lot. This is a fantastically awesome answer.
    – jsv
    Apr 12 at 11:49
  • 1
    Your first example actually prints undefined false true, not false false true. It doesn't matter if you have if (x) because undefined is falsy, but if you're doing something else with x, the two function definitions are not equivalent.
    – Jasmijn
    Apr 13 at 19:15
  • @Jasmijn Good catch. Changed the printed value to x == true to fix that.
    – Flater
    May 1 at 15:16
2

As for whether it is "usually recommended", the answer is no. However, there are cases where a default value for a boolean makes sense.

Something to consider: I suggest that the default value usually be false. That way the behavior is "as expected in JS": a missing parameter is falsy.

This may mean that the name of the parameter gets switched. For example, if the method deletes all nodes, with an option for recursive, and the "most typical" behavior should be recursive is true, I suggest

deleteNodes(parent, dontRecur)

instead of

deleteNodes(parent, recur=true)

YMMV. If the reversed name is just too corny or unexpected, don't follow this advice.

1
  • 1
    I started to think this way in every language. If you have a boolean it's easier to assume it's false by default, so it becomes falsy when omitted in such languages. Unfortunately, this rule will break for public APIs where the default behavior needs to be changed. You should not change the variable name when the default value changes. If it's private I often rather refactor, though. Apr 13 at 21:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.