[EdgarVerona]

This one's definitely a weakness I still have. I read that and thought "yeah, I do this in a lot of places and often end up regretting it."

I think named parameters don't actually help, because the underlying problem with the boolean (aside from the mystery about what it means when looking at code calling it) is that it implies a potential separate "mode" of operation for the function. That the single function might actually serve two different purposes. It doesn't always imply that I imagine, but it's pretty likely.

I'm guilty of this in my code, and I know that my code quality has suffered for it - for some reason, the way he put it in this article gave me a moment of introspection there, and it's something I'm going to try and take away from it and improve my own code with in the future.

[tabtab]

However, using multiple names can create a combinatorial explosion. If you have 3 Boolean parameters, then you need up to 8 functions. I think named parameters are probably a better option.

[pavon]

Only if you really need all combinations of those options. The flip-side is true as well - multiple booleans creates a combinatorial explosion of corner cases that you have to test for. I have definitely been guilty of adding flags to functions that really should have been separate functions, and being bit by permutations that were not tested. Some of which we couldn't even decide what the proper behavior ought to be when we went back to fix the function.

[tabtab]

Wouldn't those same combos need to be tested regardless of which interface technique is used? If there are 8 variations then there are 8 variations regardless of the name-centric or flag-centric approach.

Note that sometimes I add an optional boolean parameter to avoid breaking existing method calls. The default of the new optional flag is the original behavior. It's a case being backward compatible versus changing more code in order to fit a revamped interface.