boolean parameters -- do they smell?

Question

I just found a bug caused by a boolean parameter... the caller thought it was controlling one thing but it was really controlling something else. So do boolean parameters smell in general? Personally, I don't feel comfortable when I see them. I mean:

DoSomething(false);

What the heck am I supposed to think when I read something like that?!

Answer 1

Not at all.

Sometimes you need a method to perform some operation in one fashion or another depending on the situation. And when in your software you need one way or another is usually clear.

Also when you refactor software you need to extend some method behavior. In order not to break the old code you just add one more parameter to the method signature and then add an "old" shorter version of the method calling the long one with some parameter set to a fixed value.

For example:

You have somewhere in your code:

public void SendOrder (Guid customerID, ShipmentOptions options);

It also sends automatically a confirmation email.

Now you decide to add, say, an automated system order feature where you do not wish the emails to be sent. And you also wish to keep the old code intact. So you extend it:

public void SendOrder (Guid customerID, ShipmentOptions options,
                       bool sendConfirmationEmail);

and add a short version for backwards compatibility:

public void SendOrder (Guid customerID, ShipmentOptions options)
{
    public void SendOrder (customerID, options, true);
}

So boolean parameters are just fine.

Answer 2

What the heck am I supposed to think when I read something like that?!

I'd say pretty much the same thing you'd think if you saw DoSomething(5). If you aren't sure what the API of a given function is, then it's best to look at the function definition. There's nothing wrong with a boolean parameter any more than there's something wrong with a parameter of any other type. If the caller doesn't know the API, no amount of data type gymnastics will help that.

Answer 3

As per here:

Do not use Booleans unless you are absolutely sure there will never be a need for more than two values.

Answer 4

Boolean parameters are fine, especially when in modern IDEs you can hover over them and get help on what the parameter is for.

If you are using the same bool in multiple methods, consider replacing it with an enum. This has several benefits:

• Code is much more readable
• It's harder to make a mistake and pass in the wrong value
• It's much easier to refactor later if you realise you need a third option!
• All functions that take the value have a common, consistent API

Answer 5

It works in situations where the function name is clear. In your example the confusion is more from what is "something".

If the function call was ShowWindow(true), it's pretty clear what is going on.

However, if a method takes multiple parameters, and you have a boolean being used as a flag then I can see confusion. ShowWindow(123, 321, x, y, true) is not immediately clear, and an enumeration instead of a boolean would make it legible: ShowWindow(123, 321, x, y, POSITION.ONTOP).

Answer 6

From an OOP perspective, it is nice for the object state to handle that but from a simplicity perspective, it's just two states you have to worry about and test. I would say it's a smell but not one worth refactoring away as a high priority. The code would really start to smell if you were using a switch statement.

Answer 7

Boolean parameters don't smell, but they are often misused.

A parameter should be a boolean if it's obvious that the two "options" are "True" and "False". For example, for a method like this, boolean is perfect:

SetVisibility(true)

However, if the meaning does not explicitly mean true or false, I think an enum is nearly always a better option. This also opens up the possibility for more than 2 meanings, which is very valuable.

Answer 8

In a language like Objective-C, this isn't really a problem. Any method call contains the name of the parameters, and so it becomes very clear what is supposed to happen; e.g.:

[someObject doSomething: something animated: YES];

Answer 9

The problem (in this particular example) is not with the boolean parameter itself, but with the name of the method that contains it

Answer 10

Boolean flags are iffy. They imply the routine uses logical (flag) cohesion. That's a lower level of cohesion than is ideal. The only worse kind is "Coincidental" (basicly no cohesion). You should generally try to avoid it if you can. The typical fix is to split the routine into two. But sometimes it is the simplest and clearest way to do things.

What the heck am I supposed to think when I read something like that?!

Well, this is why languages should have named parameters. In Ada the code could read:

DoSomething (WithKetchup => false)

Languages which allow named parameters in the calls include: Ada, Python, Ruby and Javascript.

Answer 11

I use this C++ convention:

DoSomething (false /* WithKetchup */);

Answer 12

I think there is no problem with boolean params, but it can be troublesome if they are used carelessly (as it seems in your situation).

• If you have a signature like: createAnimation(boolean isTemp), the best choice would be to separate the method into 2. createAnimation() and createTempAnimation().

• If you have an "one way method" like: setVisible(true), a boolean would be just fine, since the name of the method is readable. Anyway, if you have access to change the code, modify it like that to keep it more readable. But if you don't have you should just read the function definition

Answer 13

This guy will likely tell you that too many parameters and especially boolean parameters are definite code smells. I highly recommend his book, Clean Code.

The problem with APIs like

SendOrder( order, true );

is that they tend to rot and become something like:

SendOrder( order, false, true, 0, null, etc );

Answer 14

In Ruby, I try to use options hashes as often as possible.

do_something(:with_ketchup => true, :with_mustard => false)

You can use booleans, and you know exactly what they mean.

Answer 15

for loops, while loops, do loops, if/then/else statements, C&C++ ternary ?: operator all use boolean values implicitly.

Your example is one of bad code (the function name gives no indication of what it does so what does false indicate?), but not demonstrative of anything in particular about boolean variable.

I think your question is like those we get about pointers: "I found a bug with use of a pointer, so are pointers bad?". Seems to me like the tradesman blaming his tools.

Answer 16

But it seems in c & c++, one has to agree that (in cases unlike setVisible(bool) below) they hinder readability when passed as true and false

It is more work for the interface designer but

typedef enum {PLAIN,KETCHUP} condiments; 
burger makeBurger(condiments);

.....

burger mine = makeBurger(PLAIN);
burger yours= makeBurger(KETCHUP);

enforces an increased level of readability at the invokation site. And since the interface is done infrequently compared to invokations(programmers eat a lot of burgers!) why not do the interface this way.

So to me the the problem really is allowing the caller to not document the meaning of the call when there is a not immediately evident meaning.

Documentation at the invokation site may be enforced by coding standards,a bit more carefully designed interface, or the language.

Answer 17

I agree with other posters, it's not the boolean value that's the problem, it's the lack of context for the hard-coded constant.

One thing I did recently in an embedded C++ progam when calling a function in my RTOS that takes a boolean parameter is to say what the param is in a C-style comment:

QueueMessage(/*from ISR*/false);

or

QueueMessage(/*from ISR*/true);

Each line of code would be called either from an interrupt service routine or not from an interrupt service routine, so no variable was needed, but it left a reader a little confused as to what the param was doing.

Back in the day in Ada we could use named parameters:

MyFunc(Param1Name => p1, Param2Name => p2);

and it was very clear what each parameter was. Especially nice was that you could list the params in any order, or leave out any number of default parameters. Too bad more languages don't do that.

Answer 18

DoSomething(false);

Is a great example of non-self documenting code.

Lets assume that DoSomething, when it is passed false, does a "Dry run" (using PHP here)

define('DRY_RUN',false);
DoSomething(DRY_RUN);

is a lot more readable !

So, yes, they potentially are code smells, except maybe in the case of :-

setVisible(true);

or similar

Answer 19

In languages with weak typing (Perl, PHP, Javascript, Ruby), I like to pass strings to boolean parameters to document them (if true, that is):

$x = send_mail ($addr, $message, "log", "require_reciept");

Its not a great convention, but better than:

$x = send_mail ($addr, $message, true, true);