Boolean parameters to API functions considered harmful (2011)

Alternate (better) solution to the author's problem: Use enums

It's perfectly fine if your function takes a boolean argument where the parameter either means "TRUE" or "FALSE": EnableThing(bool) is self-descriptive (as long as passing TRUE enables the thing... too many APIs fall victim to this total failure as well).

The real problem is when you start using booleans where you lose the meaning. Mapping boolean to things that take on similar meanings { 0, 1 }, { NO, YES }, { OFF, ON }, and maybe stretching it a bit, { BLACK, WHITE } is probably okay as long as it is clearly spelled out what the flag is doing, and likely it should be the only parameter to the function (and definitely not when there are multiple flags, and especially definitely not when those flags have some interaction). Mapping boolean to { PURPLE, YELLOW }, { LEFT TO RIGHT, RIGHT TO LEFT }, or { SYNCHRONOUS, ASYNCHRONOUS } is asking for people to misuse your API, and worse - painting yourself into the corner when it comes time to handle BLUE, TOP TO BOTTOM, or ISOSYNCHRONOUS. In many of these cases, you're far better off just throwing in the ten second enum. ("Functions are cheap" is true for applications, but it's categorically false for libraries, especially those that must stand up to the test of time, so I would definitely stick to the enum - types really are cheap.)

His given example is definitely an example of doing it wrong, but I have a better one that I come across every day at my job:

   gtk_box_pack_start (Box, Widget, bool expand, bool fill, int padding);

#2. One boolean changes the behavior of the other. We don't have a complete mapping; only three of the four states are meaningful.

#3. The API is not expressive enough to tell you what expand/fill mean without looking at the documentation, so you have to "do the matrix" and start seeing blonde, brunette, redhead by memorizing the order of the flags.

An enumeration would tell you immediately, and be roughly as character efficient as "FALSE, FALSE", "TRUE, FALSE" or "TRUE, TRUE":

    enum GtkBoxPackingOptions
    {
       PACK_SHRINK,
       PACK_EXPAND_PADDING,
       PACK_EXPAND_WIDGET
    };

    foo.frob(true, false, true);

The »two methods, distinguished in name« works fine, as long as you only have a single boolean argument and API growth won't ever happen around that point. Other options that often scale better would be enums, or a parameter object encompassing options, if there are many.

  /* caller */
  doSomething (arg1, arg2, XYZ_SYNC);

  /* platform 1 */
  #define XYZ_SYNC 0
  #define XYZ_ASYNC 0x01

  /* platform 2 */
  #define XYZ_SYNC 0x01
  #define XYZ_ASYNC 0

    document.addObserver(observer, "load", Yes.isWeak);

    xhr.OpenUrl(url, options, No.sync)

And also, it is not the parameter type that is harmful here, but rather how the parameter is named and used. Let me just quote 2nd edition of Code Complete, which was written over 10 years ago: "give boolean variables names that imply true or false". Very simple, almost obvious piece of advice that summaries the problem on hand better than all this post.

Too bad that they really screwed that up with ES6:

    function foo({a = 1, b = 2} = {}) {...}

    foo({a: 1, b: 2}) {...}

    function foo({a = 1, b = 2, c} = {c: 3}) {
      console.log(a, b, c);
    }
    foo();         // 1 2 3
    foo({a: 'a'}); // a 2 undefined
    foo({c: 'c'}); // 1 2 c

    function foo({length = 2} = 'foobar') {
      console.log(length);
    }
    foo();            // 6
    foo({length: 0}); // 0
    foo({x: 'x'});    // 2

I really don't understand why they prioritized this kind of excessive flexibility over tooling. Now you can put entire programs into a function's signature. Why would anyone want that?

    (async ? dispatch_async : dispatch_sync)(queue, ^{
        /* stuff */
     });

https://existentialtype.wordpress.com/2011/03/15/boolean-bli...

  Xhr.open(type, url, Xhr.ASYNC);

  function addObserver(observer, func, { weak = false } = {}) {
    if (weak) {
      // ...
    }
  }

  addObserver(observer, 'load', { weak: true });

   enableOutput(bool)

This is a more superficial explanation of why they're bad: they're hard to name. I agree. More deeply: they also scale horribly. Boolean parameters often are used to switch off to a meaningfully different function, and when they accumulate, you have 2^n different cases. At n = 6, you have two anti-patterns: a function with at least 6 parameters and probably more, and quite possibly 64 different use cases. How likely is it that those parameters all play well together? It's quite probable that there are combinations of the parameters that don't make any sense together.

They also don't extend well. If you move from 2 cases to 3, the common behavior (by a maintenance programmer who doesn't understand the code well and is working to deadline, so forgive him) is to add another boolean parameter rather than refactor it to an enum or union. Then you have a "case2" and "case3" boolean parameter and get the problem described above: 4 possibilities, 1 of which is meaningless.

With named, optional arguments, boolean parameters can be fine-- if you know that there will never be more than 2 cases. Sometimes they're the right thing. That said, they're a code smell (not always bad, but suggestive that you might be doing something wrong) and I'd almost never use them in Haskell, which (although a great language) doesn't have named arguments, because it's so easy to create your own datatype (that is easier to extend than a boolean).

Seriously, it's 2015, I shouldn't have to worry about getting my arguments out of order and slipping into production code. Test your code, pick a better language, or hell, use enums. Instead we get one hell of a click-bait headline and a very specious argument.