Take the 2-minute tour ×

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:


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

share|improve this question
I don't like the term 'code smell' –  Erix Aug 6 '09 at 20:01
You down voted for that? Or is that just a side comment? –  GManNickG Aug 6 '09 at 22:43
@gunslingeres: I don't like people that include misspelled words (or, in your case, extraneous characters) in their profile name. That doesn't mean that I would downvote someone because of it. –  Adam Robinson Aug 6 '09 at 22:55
But you can do it –  Jaime Pardos Aug 7 '09 at 20:25
Additional reading: “The Boolean Trap” –  cbowns Oct 4 '12 at 17:12
show 3 more comments

19 Answers

up vote 46 down vote accepted

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:


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.

share|improve this answer
I prefer SetVisibility(visible) and SetVisibility(invisible). –  BoltBait Aug 6 '09 at 19:15
It should be SetVisibility() and SetInvisibility(). ;-) –  Nosredna Aug 6 '09 at 21:54
I hate the Set... pattern. That's what properties are for in the first place. –  Reed Copsey Sep 1 '09 at 15:24
Hide() and Show() anyone? –  Kevin Jun 3 '11 at 13:04
I hate when APIs use SetVisible/SetInvisible, or Enable/Disable, rather than SetVisible(boolean) or Enable(boolean), because you invariably end up writing something like if (shouldBeVisible) SetVisible() else SetInvisible() rather than the more succinct SetVisible(shouldBeVisible). –  Mud Jun 22 '12 at 5:30
show 6 more comments

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.

share|improve this answer
Your code actually demonstrates the problem pretty well - looking at a call to SendOrder, it is immediately obvious what customerID and options mean, but the meaning of true is unclear and requires actually looking at parameter name. –  Pavel Minaev Aug 6 '09 at 21:57
add comment


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.

share|improve this answer
I like putting comments on the function declaration and definition to explain any such parameters, myself. –  David Thornley Aug 6 '09 at 19:12
Agreed - and some languages make it more readable with keyword parameters, e.g. DoSomething(:allowCached => false) –  Harold L Aug 6 '09 at 19:12
RTFM is of course a good idea. But some of us also believe that APIs should to a certain extent be self-documenting, and boolean parameters are a known problem in that area. –  anon Aug 6 '09 at 19:17
I hate the SO comment mechanism so much! I meant to say that the API should be self-documenting, but so should the API call. –  anon Aug 6 '09 at 19:25
@Neil: I agree that the call should be self documenting, but I also think that you shouldn't choose another data type altogether just because a boolean's purpose might not be immediately obvious. –  Adam Robinson Aug 6 '09 at 19:28
show 13 more comments

As per here:

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

share|improve this answer
And be sure not to use an integer of you need to represent a fraction. And don't use any other data type that can't hold the data that it needs to represent... –  Adam Robinson Aug 7 '09 at 0:10
add comment

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
share|improve this answer
add comment

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).

share|improve this answer
Yes, in my (buggy) situation, the boolean was actually one of several parameters. –  JoelFan Aug 6 '09 at 20:13
add comment

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.

share|improve this answer
add comment

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];
share|improve this answer
add comment

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

share|improve this answer
It's both. Some names make sense with a boolean parameter, while others are ambiguous. We should prefer the former, of course, but also be willing to use an enum if that's what it takes to be clear. –  Steven Sudit Aug 17 '09 at 16:48
(To be clear, I do agree that the name is a part of it, so +1) –  Steven Sudit Aug 17 '09 at 17:03
I'm almost certain that was a placeholder name. Could have easily been foo(true) –  Eva Mar 5 '13 at 22:21
add comment

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.


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.

share|improve this answer
In some languages you can pass in an object you build on the fly. JavaScript: doSomething({withKetchup : true , withMustard : false , withMayo : false}); –  Nosredna Aug 6 '09 at 21:59
I edited this answer to include some other languages apart from Ada that support this. (Although Ada was the first language I saw that did this.) I am just trying to prevent the same answer being posted repeatedly, with the only difference between the language name. –  Oddthinking Feb 21 '10 at 8:06
Good addition. Thanks. –  T.E.D. Feb 22 '10 at 13:51
C# also allows named parameters from version 4.0 onward. –  Stefano Ricciardi Feb 25 at 14:06
add comment

I use this C++ convention:

DoSomething (false /* WithKetchup */);
share|improve this answer
The nice thing about Ada is that this "convention" is checked by the compiler. Eg: If you mess up the order, it makes sure the right actual parameter goes to the right formal. –  T.E.D. Aug 6 '09 at 21:32
OK - until the next maintenance programmer doesn't bother updating the comments... –  Simon Oct 22 '10 at 13:55
Comments should say why not what. –  Eva Mar 5 '13 at 22:39
Comments should say whatever is necessary to disambiguate the functionality and purpose of code for a person reading it. –  Troy Alford Mar 5 '13 at 22:42
add comment

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

share|improve this answer
add comment

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 );
share|improve this answer
the code I debugged was like your 2nd ("rotten") example. –  JoelFan Aug 6 '09 at 20:15
add comment

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.

EDIT - I'm revisting this 2.5 years later to point out that in .Net3+, you can do this as well.

DoSomething(withKetchup: true. withMustard: false);
share|improve this answer
add comment

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.

share|improve this answer
Control flow is different from parameters. They are very specific, so while(true) is obvious. (Though when you're not using an infinite loop, it is still recommended to use well named conditionals). If something causes more bugs than an alternative way in the same language, you should avoid/eliminate that. Pointers are a good example of things to avoid in C++, (smart pointers are usually better) and things to never use in C# (unless you have a particular job that requires it). –  Eva Mar 5 '13 at 22:38
add comment

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.

share|improve this answer
i like more than one condiment –  Jim Aug 6 '09 at 20:56
"no coke, pepsi" - John Belushi –  pgast Aug 6 '09 at 21:36
add comment

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);


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.

share|improve this answer
add comment

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)


is a lot more readable !

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


or similar

share|improve this answer
add comment

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);
share|improve this answer
add comment

Your Answer


