

Hall of API shame: Boolean trap (2011) - fooyc
http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html

======
h2s
This is by far the number one API design anti-pattern in terms of how
widespread it is. It's like bad kerning: once you've seen it, it's everywhere,
and nobody seems to notice.

It usually results from writing code with a short-sighted focus on achieving
some bespoke functionality in the least possible time. Somebody wants to
disable a piece of behaviour in a function, they know where the code is, they
wrap it in an if statement and throw another optional boolean parameter onto
the pile.

It's symptomatic of functions, methods or subroutines that are _too long_.
Functions should do one thing at one level of abstraction, and the very
possibility of a boolean parameter means that your function is doing at least
two things.

------
przemoc
Boolean parameter can be useful (for DRY-ness, etc.), but to prevent any
misunderstandings, I almost always introduce descriptive constants in such
cases:

    
    
      const bool SOMETHING = false;
      const bool OTHERTHING = true;
    

and use them strictly for such parameter.

When there is a default parameter value, sometimes even only one constant can
be enough (for non-default variant description).

