Share via

Boolean Parameters

  • Article

An item I try to avoid in any API I create are methods which ...

  1. Take more than one parameter
  2. One of the parameters is a boolean

Typically this pattern indicates a True/False option on an operation type.  This boolean value turns on or off some type of scenario for that operation. 

The reason I dislike this is that it's not maintainable.  I constantly forget what the boolean value means and it makes my code less readable to people who are reviewing.  The reviewer sees SomeOperation(1, true) and they constantly ask "What does true mean?".  And even though most programmers won't admit this, years after you write the code and you're tracking down a bug, you also forget what true meant in this case.

Instead I prefer to break down the operation into three different methods.  Say the operation in question loaded a particular piece of data from a file.  The data block can have references to other data blocks.  In some cases I only want the first layer of data and in others I would like to load all referencable data blocks.  Here is the break down of operations I will create.

  1. public LoadDataBlock(identifier)
  2. public LoadDataBlockRecursive(identifier)
  3. private LoadDataBlockImpl(identifier, recursive)

The private implementation takes the boolean indicating the option.  This gives the implementor of the method the flexibility of having the boolean option parameter.  The big win here is for the caller.  They don't need to know about this hidden parameter and instead will have two clear API method calls.

Comments

  • Anonymous
    January 23, 2007
    Good post.  I would also suggest another alternative is to replace the boolean parameter with an enumeration parameter.  This helps the user better comprehend the API, without introducing a member function with a separate name.

  • Anonymous
    January 23, 2007
    Exactly! This practice (of 2 different methods) is most fit for purpose. Enumeration is rarely a good idea, because all this stuff is like a smokescreen. It looks cool, and complex, and smart. But actually the purpose is simple, so the solution would be easy. Keep it simple, you know. It's like using long wise words to say simple thing, like saying 'I am willing to elevate me up to the floor number 4' instead of '4th, please'.

  • Anonymous
    January 24, 2007
    I think enum's in certain situations are also a good alternative.  The main goals are clarity and maintainability and enums definately fit the clarity part and mostly maintainability.   The only reason I would avoid enums is typespace polution.  If the enum existed for another reason (say to describe the state of data in general) then it would be fairly natural to have it be a parameter.  Especially if there were more than 2 types of data (Say Recursive, singleLevel, SomeRandomConfiguration).  In that case I would definately choose an enum.

  • Anonymous
    October 29, 2007
    This is another recount of an experience I had refactoring some C++ code recently. In some ways this