Live data from Hacker News

Get rid of those boolean function parameters (2015)

mortoray.com

1–10 of 119 posts

Re: Get rid of those boolean function parameters (2015)

#2
I agree that using booleans like this can be confusing. But, imo, it's more confusing to have a bunch of wrapper functions that create abstraction madness.

I mostly write computation/math-related code and I find using named arguments to be a good practice. This is also quite similar to OP's enum approach, e.g. sth like `calc_formula(a, b, is_gain=True)`.

To be fair, the older I get, the more I like explicit arguments for everything like in Swift (and smalltalk iirc).

Re: Get rid of those boolean function parameters (2015)

#4
As pointed out in some of the article's comments, a much better solution would be if all languages allowed putting the name in front of function parameters (and while at it, also not enforce a specific parameter order and skip default-value parameters).

A workaround in C99 (and more limited in C++20) is to use a single struct which bundles all the function parameters, and then use designated initialization, this also makes function paramaters optional, and at least in C99 they can appear in any order:

    my_func((my_struct_t){
        .a_bool_flag = true,
        .another_bool_flag = false,
        .a_string = "Hello World"
    });
This is mainly useful for functions which take many parameters. One downside in C99 (but not C++) is that there's no way to define default values for struct items (other than zero/false).

Re: Get rid of those boolean function parameters (2015)

#5
post #3

In python, I love keyword-only arguments for this. Then the caller has to write: v = calc_formula(ia, ib, is_gain=true) You also have the option of defining a default value for the argument so the old call-sites don't even need modification.

In C++ I’ve gotten in the habit of `enum class is_gain : bool { no, yes };` so the call site is `v = calc_formula(ia, ib, is_gain::yes);`. An advantage is that such stron Boolean-like types can be passed repeatedly and maintain their type safety.

Re: Get rid of those boolean function parameters (2015)

#8
post #6

This should really be solved by using named parameters or by writing docblocks so that IDE can show hints. Another trick, at least in js, is to use destructuring assignment, e.g. function calc_formula({a, b, is_gain}){ ... } calc_formula({a:1, b:2, is_gain:true})

My rule of thumb these days in JS/TS is all functions with more than 2 parameters should be refactored to a single object parameter using destructuring. I don't start with a single object because most times YAGNI applies.

Re: Get rid of those boolean function parameters (2015)

#10
It is a bane of numerical code, in which there are many flags, quite a few parameters (with values 0. or 1.). Moreover, some flags are conditional (e.g. the value of the argument 5 matters only if the flag at position 3 is true).

In a much simpler case of arcs in SVG, I still need to check flags to do the correct path (https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/Pa...).

Post reply on HN