5 ms·

A piece of advice I read somewhere early in my career was "a boolean should almost never be an argument to a function". I didn't understand what the problem was

by OskarS 1y ago

A piece of advice I read somewhere early in my career was "a boolean should almost never be an argument to a function". I didn't understand what the problem was at the time, but then years later I started at a company with a large Lua code-base (mostly written by one-two developers) and there were many lines of code that looked like this: serialize(someObject, true, false, nil, true) What does those extra arguments do? Who knows, it's impossible without looking at the function definition. Basically, what had happened was that the developer had written a function ("serialize()", in this example) and then later discovered that they wanted slightly different behaviour in some cases (maybe pretty printed or something). Since Lua allows you to change arity of a function without changing call-sites (missing arguments are just nil), they had just added a flag as an argument. And then another flag. And then another. I now believe very strongly that you should virtually never have a boolean as an argument to a function. There are exceptions, but not many.

arethuza 1y ago
If you use keyword arguments then something like that doesn't look too bad: serialize(someObject, prettyPrint:true) NB I have no idea whether Lua has keyword arguments but if your language does then that would seem to address your particular issue?
- OskarS 1y ago
  Lua doesn't directly support keyword arguments, but you can simulate it using tables: serialize(someObject, { prettyPrint = true }) And indeed that is a big improvement (and commonly done), but it doesn't solve all problems. Say you have X flags, then there's 2^X different configurations you have to check and test and so forth. In reality, all 2^X configurations will not be used, only a tiny fraction will be. In addition, some configurations will simply not be legal (i.e. if flag A is true, then flag B must be as well), and then you have a "make illegal states unrepresentable" situation. If the tiny fraction is small enough, just write different functions for it ("serialize()" and "prettyPrint()"). If it's not feasible to do it, have a good long think about the API design and if you can refactor it nicely. If the number of combinations is enormous, something like the "builder pattern" is probably a good idea. It's a hard problem to solve, because there's all sorts of programming principles in tension here ("don't repeat yourself", "make illegal states unrepresentable", "feature flags are bad") and in your way of solving a practical problem. It's interesting to study how popular libraries do this. libcurl is a good example, which has a GAZILLION options for how to do a request, and you do it "statefully" by setting options [1]. libcairo for drawing vector graphics is another interesting example, where you really do have a combinatorial explosion of different shapes, strokes, caps, paths and fills [2]. They also do it statefully. [1]: https://curl.se/libcurl/c/curl_easy_setopt.html https://curl.se/libcurl/c/curl_easy_setopt.html [2]: https://cairographics.org/manual/cairo-cairo-t.html https://cairographics.org/manual/cairo-cairo-t.html
lelanthran 1y ago
It's a failing of many type systems of older languages (except Pascal). The best way in many languages for flags is using unsigned integers that are botwise-ORed together. In pseudocode: Object someObject; foo (someObject, Object.Flag1 | Object.Flag2 | Object.Flag3); Whatever language you are using, it probably has some namespaced way to define flags as `(1 << 0)` and `(1 << 1)` etc.
- arethuza 1y ago
  If you really need all of that I think I'd go with a separate object holding all of the options: options = new SerializeOptions(); options.PrettyPrint = true; options.Flag2 = "red" options.Flag3 = 27; serialize(someObject, options)
  - vanviegen 1y ago
    So 1 line of C/C++ becomes 5 lines of Java/C#? That sounds about right! :-) Though I'm sure we can get to 30 if we squeeze in an abstract factory or two!
    - wallstop 1y ago
      You can do the above in C#, I haven't written Java in a decade so can't comment on that. I don't really understand your argument though - the options approach is extremely readable. You can also do the options approach in C or C++. The amount of stuff that you can slap into one line is an interesting benchmark to use for languages.
- dandersch 1y ago
  It's always crazy to see languages like C being able to beat high-level languages at some ergonomics (which is usually their #1 point of pride) just because C has bitfields and they often don't.
- RaftPeople 1y ago
  > The best way in many languages for flags is using unsigned integers that are botwise-ORed together. Why is that the "best" way?
account42 1y ago
But this isn't really a boolean problem - even in your example there is another mistery argument: nil And you can get the same problem with any argument type. What do the arguments in copy(obectA, objectB, "") mean? In general, you're going to need some kind of way to communicate the purpose - named parameters, IDE autocomplete, whatever - and once you have that then booleans are not worse than any other type.
- 8-prime 1y ago
  True, but I think its worth noting that inferring what a parameter could be is much easier if its something other than a boolean. You could of course store the boolean in a variable and have the variable name speak for its meaning but at that point might as well just use an enum and do it proper. For things like strings you either have a variable name - ideally a well describing one - or a string literal which still contains much more information than simply a true or false.
  - nomel 1y ago
    If you language doesn't support named arguments, you can always name the value, with the usual mechanism: debug_mode=True some_func(..., debug_mode)
- OskarS 1y ago
  You're correct in principle, but I'm saying that "in practice", boolean arguments are usually feature flag that changes the behavior of the function in some way instead of being some pure value. And that can be really problematic, not least for testing where you now aren't testing a single function, you're testing a combinatorial explosions worth of functions with different feature flags. Basically, if you have a function takes a boolean in your API, just have two functions instead with descriptive names.
  - hamburglar 1y ago
    > Basically, if you have a function takes a boolean in your API, just have two functions instead with descriptive names. Yeah right like I’m going to expand this function that takes 10 booleans into 1024 functions. I’m sticking with it. /s
nutjob2 1y ago
> I now believe very strongly that you should virtually never have a boolean as an argument to a function. There are exceptions, but not many. Really? That sounds unjustified outside of some specific context. As a general rule I just can't see it. I don't see whats fundamentally wrong with it. Whats the alternative? Multiple static functions with different names corresponding to the flags and code duplication, plus switch statements to select the right function? Or maybe you're making some other point?
0x3444ac53 1y ago
I think the answer to this (specific to lua) is passing a table as an argument that gets unpacked.
StopDisinfo910 1y ago
Named arguments are a solution to precisely this issue. With optional arguments with default value, you get to do precisely what was being done in your Lua code but with self documenting code. I personally believe very strongly that people shouldn’t use programming languages lacking basic functionalities.
- _dain_ 1y ago
  Named arguments don't stop the deeper problem, which is that N booleans have 2^N possible states. As N increases it's rare for all those combinations to be valid. Just figuring out the truth table might be challenging enough, then there's the question of whether the caller or callee is responsible for enforcing it. And either way you have to document and test it. Enums are better because you can carve out precisely the state space you want and no more.
  - fluoridation 1y ago
    That's not a problem per se. It may very well be that you're configuring the behavior of something with a bunch of totally independent on/off switches. Replacing n booleans with an enum with 2^n values is just as wrong as replacing a 5-valued enum with 3 booleans that cannot be validly set independently.
- lukan 1y ago
  Or not use them without tooling? I believe IDE's had the feature of showing me the function header with a mouse hover 20+ years ago.
- kevin_thibedeau 1y ago
  You can also document the argument name inline for languages with block comments but no named args.
  - StopDisinfo910 1y ago
    You can but it’s not the same because the names of named arguments are also present at the call site.
Lyngbakr 1y ago
I don't know if this is where you read it, but this advice is also given in Clean Code.
- OskarS 1y ago
  I don’t remember exactly where I read this, but I think it was some internet forum of some kind. It makes sense that whoever wrote it got it from there. Never read it myself.
mostlysimilar 1y ago
Something I really love in Elixir is that functions can be named identically and are considered different with different arity. https://elixirschool.com/en/lessons/basics/functions#function-naming-and-arity-3 https://elixirschool.com/en/lessons/basics/functions#functio...
- hatthew 1y ago
  I'm not sure I understand how this is different from function overloading
Vinnl 1y ago
I die a little inside every time I write: JSON.stringify(val, null, 2); (So yes, but it goes beyond booleans. All optional parameters should be named parameters.)
drdec 1y ago
I'm surprised nobody has suggested this yet. Just use a different name for the function. In your example, the new function should be prettyPrint(). No booleans required. No extra structures required.

by OskarS 1y ago

arethuza 1y ago

If you use keyword arguments then something like that doesn't look too bad: serialize(someObject, prettyPrint:true) NB I have no idea whether Lua has keyword arguments but if your language does then that would seem to address your particular issue?

OskarS 1y ago
Lua doesn't directly support keyword arguments, but you can simulate it using tables: serialize(someObject, { prettyPrint = true }) And indeed that is a big improvement (and commonly done), but it doesn't solve all problems. Say you have X flags, then there's 2^X different configurations you have to check and test and so forth. In reality, all 2^X configurations will not be used, only a tiny fraction will be. In addition, some configurations will simply not be legal (i.e. if flag A is true, then flag B must be as well), and then you have a "make illegal states unrepresentable" situation. If the tiny fraction is small enough, just write different functions for it ("serialize()" and "prettyPrint()"). If it's not feasible to do it, have a good long think about the API design and if you can refactor it nicely. If the number of combinations is enormous, something like the "builder pattern" is probably a good idea. It's a hard problem to solve, because there's all sorts of programming principles in tension here ("don't repeat yourself", "make illegal states unrepresentable", "feature flags are bad") and in your way of solving a practical problem. It's interesting to study how popular libraries do this. libcurl is a good example, which has a GAZILLION options for how to do a request, and you do it "statefully" by setting options [1]. libcairo for drawing vector graphics is another interesting example, where you really do have a combinatorial explosion of different shapes, strokes, caps, paths and fills [2]. They also do it statefully. [1]: https://curl.se/libcurl/c/curl_easy_setopt.html https://curl.se/libcurl/c/curl_easy_setopt.html [2]: https://cairographics.org/manual/cairo-cairo-t.html https://cairographics.org/manual/cairo-cairo-t.html

lelanthran 1y ago

It's a failing of many type systems of older languages (except Pascal). The best way in many languages for flags is using unsigned integers that are botwise-ORed together. In pseudocode: Object someObject; foo (someObject, Object.Flag1 | Object.Flag2 | Object.Flag3); Whatever language you are using, it probably has some namespaced way to define flags as `(1 << 0)` and `(1 << 1)` etc.

arethuza 1y ago
If you really need all of that I think I'd go with a separate object holding all of the options: options = new SerializeOptions(); options.PrettyPrint = true; options.Flag2 = "red" options.Flag3 = 27; serialize(someObject, options)
- vanviegen 1y ago
  So 1 line of C/C++ becomes 5 lines of Java/C#? That sounds about right! :-) Though I'm sure we can get to 30 if we squeeze in an abstract factory or two!
  - wallstop 1y ago
    You can do the above in C#, I haven't written Java in a decade so can't comment on that. I don't really understand your argument though - the options approach is extremely readable. You can also do the options approach in C or C++. The amount of stuff that you can slap into one line is an interesting benchmark to use for languages.
dandersch 1y ago
It's always crazy to see languages like C being able to beat high-level languages at some ergonomics (which is usually their #1 point of pride) just because C has bitfields and they often don't.
RaftPeople 1y ago
> The best way in many languages for flags is using unsigned integers that are botwise-ORed together. Why is that the "best" way?

account42 1y ago

But this isn't really a boolean problem - even in your example there is another mistery argument: nil And you can get the same problem with any argument type. What do the arguments in copy(obectA, objectB, "") mean? In general, you're going to need some kind of way to communicate the purpose - named parameters, IDE autocomplete, whatever - and once you have that then booleans are not worse than any other type.

8-prime 1y ago
True, but I think its worth noting that inferring what a parameter could be is much easier if its something other than a boolean. You could of course store the boolean in a variable and have the variable name speak for its meaning but at that point might as well just use an enum and do it proper. For things like strings you either have a variable name - ideally a well describing one - or a string literal which still contains much more information than simply a true or false.
- nomel 1y ago
  If you language doesn't support named arguments, you can always name the value, with the usual mechanism: debug_mode=True some_func(..., debug_mode)
OskarS 1y ago
You're correct in principle, but I'm saying that "in practice", boolean arguments are usually feature flag that changes the behavior of the function in some way instead of being some pure value. And that can be really problematic, not least for testing where you now aren't testing a single function, you're testing a combinatorial explosions worth of functions with different feature flags. Basically, if you have a function takes a boolean in your API, just have two functions instead with descriptive names.
- hamburglar 1y ago
  > Basically, if you have a function takes a boolean in your API, just have two functions instead with descriptive names. Yeah right like I’m going to expand this function that takes 10 booleans into 1024 functions. I’m sticking with it. /s

nutjob2 1y ago

> I now believe very strongly that you should virtually never have a boolean as an argument to a function. There are exceptions, but not many. Really? That sounds unjustified outside of some specific context. As a general rule I just can't see it. I don't see whats fundamentally wrong with it. Whats the alternative? Multiple static functions with different names corresponding to the flags and code duplication, plus switch statements to select the right function? Or maybe you're making some other point?

0x3444ac53 1y ago

I think the answer to this (specific to lua) is passing a table as an argument that gets unpacked.

StopDisinfo910 1y ago

Named arguments are a solution to precisely this issue. With optional arguments with default value, you get to do precisely what was being done in your Lua code but with self documenting code. I personally believe very strongly that people shouldn’t use programming languages lacking basic functionalities.

_dain_ 1y ago
Named arguments don't stop the deeper problem, which is that N booleans have 2^N possible states. As N increases it's rare for all those combinations to be valid. Just figuring out the truth table might be challenging enough, then there's the question of whether the caller or callee is responsible for enforcing it. And either way you have to document and test it. Enums are better because you can carve out precisely the state space you want and no more.
- fluoridation 1y ago
  That's not a problem per se. It may very well be that you're configuring the behavior of something with a bunch of totally independent on/off switches. Replacing n booleans with an enum with 2^n values is just as wrong as replacing a 5-valued enum with 3 booleans that cannot be validly set independently.
lukan 1y ago
Or not use them without tooling? I believe IDE's had the feature of showing me the function header with a mouse hover 20+ years ago.
kevin_thibedeau 1y ago
You can also document the argument name inline for languages with block comments but no named args.
- StopDisinfo910 1y ago
  You can but it’s not the same because the names of named arguments are also present at the call site.

Lyngbakr 1y ago

I don't know if this is where you read it, but this advice is also given in Clean Code.

OskarS 1y ago
I don’t remember exactly where I read this, but I think it was some internet forum of some kind. It makes sense that whoever wrote it got it from there. Never read it myself.

mostlysimilar 1y ago

Something I really love in Elixir is that functions can be named identically and are considered different with different arity. https://elixirschool.com/en/lessons/basics/functions#function-naming-and-arity-3 https://elixirschool.com/en/lessons/basics/functions#functio...

hatthew 1y ago
I'm not sure I understand how this is different from function overloading

Vinnl 1y ago

I die a little inside every time I write: JSON.stringify(val, null, 2); (So yes, but it goes beyond booleans. All optional parameters should be named parameters.)

drdec 1y ago

I'm surprised nobody has suggested this yet. Just use a different name for the function. In your example, the new function should be prettyPrint(). No booleans required. No extra structures required.