Comments on: avoid boolean parameters

By: 2005 silk and spinach top ten « silk and spinach

2005 silk and spinach top ten « silk and spinach — Tue, 30 Jun 2009 15:36:02 +0000

[...] editing in Rails 2.0setup and teardown for a ruby TestSuitea ruby sparkline showing variationavoid boolean parametersreek, a code smells detector for rubythe anti-if campaignnothing but "uses" and [...]

By: reek 0.3.0 released « silk and spinach

reek 0.3.0 released « silk and spinach — Sun, 02 Nov 2008 22:24:56 +0000

[...] main news is the arrival of a new smell: I’ve included a first naive check for the Control Couple [...]

By: the anti-if campaign « silk and spinach

the anti-if campaign « silk and spinach — Tue, 28 Oct 2008 11:19:12 +0000

[...] avoid boolean parameters [...]

By: Kevin Rutherford

Kevin Rutherford — Mon, 27 Oct 2008 08:32:51 +0000

@Moffdub: You're right -- as noted by Colin in the first comment above, a boolean parameter is a special case of the Control Coupling smell. There's a section describing Control Coupling in my imminent book, the Ruby Refactoring Workbook.

By: MoffDub

MoffDub — Sun, 26 Oct 2008 02:09:55 +0000

I think you can extend this pattern further to any parameter, be it a boolean, enumeration, or whatever, that is used inside the algorithm to branch. I started doing this earlier this week at my workplace, but immediately stopped because I knew it smelled. I applaud your articulation of this code smell.

By: Kevin Rutherford

Kevin Rutherford — Mon, 19 May 2008 20:50:12 +0000

Hi Jack, The key is that this string is input from the user. If you consider your software in terms of the hexagonal architecture pattern, the code you show would sit in an Adapter. The job of the adapters is to convert between the domain objects and the real world -- in this case to convert between the user's string and an object of the equivalent class. So it's good code (as long as it occurs only once in the system).

By: jack zhang

jack zhang — Fri, 16 May 2008 00:25:04 +0000

Kevin, your comments are correct and so the key issue here is that the system somewhere know the decision; Here I got a question for you, hope you show me how to avoid the if else use pattern or some smart ideas:
say I got input from user which is string, for example “Engineer”, “Manager”, “Saleman” etc, in my program once I get this string, I should create object of this class accordingly, I am using C++, so the straigtforward way to do it as :
if(name == “Engineer”)
return new Engineer();
else if(name == “Manager”)
return new Manager();
esle if if(name == “Saleman”)
return new Saleman();
else
return null;

I spent quite a while to see if I can use subclass to replace
the type which is string here, but still I have to swith the decision to someone else, to create concret class of type;
Do you have any idea? Thanks

By: 3 years old today! « silk and spinach

3 years old today! « silk and spinach — Sat, 16 Jun 2007 19:42:00 +0000

[...] remained popular throughout – and indeed the stats show there’s been a lot of interest in avoid boolean parameters and if… just recently – both written in July of 2004. Those two, together with the product [...]

By: Kevin Rutherford

Kevin Rutherford — Fri, 08 Jun 2007 07:38:24 +0000

@Brian:

I agree that your enums are more readable (and extensible) than the booleans. But they still suffer from the problem of duplication. The code inside the method must include conditional structures to figure out what to do. And those conditionals duplicate knowledge that’s already present in the method’s caller.

And that, in turn, means that the system as a whole is harder to maintain. Because each time we want to add a new file type, for example, we’ll have to change and/or recompile many different classes.

So it seems to me that forcing all conceptually related behaviour (creating new things in the filestore) through this one interface makes us work too hard. We have to work to make it readable, and we have to work harder when things change. Which is why I have this little rule of thumb – when I feel the need to introduce a Boolean parameter, I take a step back and re-think my object design, before it’s too late.

By: Brian

Brian — Thu, 07 Jun 2007 20:45:05 +0000

This strikes me as a perfect place to use a type-safe enumeration. Then instead of booleans, you could write something like this:
enum FileType { GenericFile, TemporaryFile }


File createFile(String name, FileType type);

// call like this: File f = FileCreator.createFile("/my/file/path", FileType.GenericFile);
This also has another benefit over booleans, namely the ability to assume more than two values. You could easily extend the enumeration like this:
enum FileType { GenericFile, TemporaryFile, Directory }
Not that this would be the best way to create a directory, of course, but it’s more straightforward than this:
File createFile(String path, boolean isTemp, boolean isDir);

By: Rob Meyer

Rob Meyer — Mon, 26 Jun 2006 20:24:08 +0000

I agree completely. In Dave’s bold/underline example, Kevin points out correctly that single functions to affect formatting in that way is probably not the ideal API, so in trying to convert said function with 4 booleans to 16 individual methods, we’ve discovered something that’s probably a code smell, which has value.

What’s more, is I’d argue that even though it’s more code and tedious for the author of the library, that the individual versions are still more readable. As an API consumer I’d still rather write:

displayTextInBoldAndUnderline()

then:

displayText(true, true, false, true);

There’s no way anyone reading the code later has a chance of understanding the 2nd one without checking out the displayText documentation, but the first one reads like English and is clear.

But Kevin’s right, fix the API, because it’s only a matter of time until someone wants that text to be able to marked superscript or subscript, and any sort of flagging technique is quickly going to get out of control.

By: kevin

kevin — Wed, 10 May 2006 22:33:15 +0000

Nico Mommaerts has posted related thoughts at http://www.hansei-kaizen.be/article/144/thissetdraftfalse-or-thispost

By: Kevin Rutherford

Kevin Rutherford — Mon, 16 May 2005 22:00:01 +0000

Responding to Dave:
I would probably tackle your displayText example using Decorators. That is, I would look for a way to create little “do it in bold” and “underline it” objects that could modify or add to the original behaviour of the text string in question. As I tried to say in hexagonal soup, the particular caller who knows which text decorations it needs will assemble the string together with the appropriate decorators at that time. The rest of the system need never know that the decorators are there. Little objects each doing one job, instead of functions doing several.

By: Kevin Rutherford

Kevin Rutherford — Mon, 16 May 2005 21:35:38 +0000

Responding to Rik:
I agree, many languages these days offer ways to render a boolean parameter more readable. However, that does nothing to remove the duplication I pointed out – that somewhere up the calling stack is another method that already knows which code path should be taken. As Colin points out, we should try to avoid that degree of interference and control.

By: Dave Kirby

Dave Kirby — Sun, 10 Apr 2005 11:24:10 +0000

Creating two different functions is fine when you only have one flag, but become a nightmare if you have more than one. For example a displayText function that can display text in any combination of bold, italic, underline and strikethrough would require 16 different functions – e.g. displayTextInBoldAndUnderline(…) etc. Having multiple functions with different names also makes it hard to change the behaviour at runtime. Here is a simple exercise: rewrite the above function into the 16 separate functions. Then write a code snippet that iterates through a list of strings and prints it in bold if it contains a ‘b’, underline if it contains a ‘u’, italic if it contains an ‘i’, and strikethrough if it contains an ‘s’. Multiple combinations are allowed, of course.As Rik says, in a modern language that allows named parameters with default values this becomes a non-issue. Python has had this facility from the start, so you can call the function as: displayText(“some text”, bold=True, underline=True)