Bool considered harmful

I’m not sure who said it recently (I think it was Haacked) but I completely agree: Never Use Bool, or more specifically never user bool as a parameter. It is the most foolish of datatypes and conveys the smallest amount of information possible. Which means that you have to add all the context of what it means to the parameter name which is not visible once your intellisense has faded. I recently came upon this little gem in my code:

Bool is bad

Function names have been changed to protect the innocent. but you get the jist. What does those boolean flags mean? I certainly don’t know! And things get even more fun when you need to refactor out one of the parameters or even worst add one in.  A far better function call would look like this:

Better without bool

Now, not only is the intention of the function explicit but also you have somewhere to go if you want more options for a parameter. I pretty sure someone covered mentioned this in the past 3-4 months but I think it’s worth re-iterating.

Of coarse it is more verbose and Atwood would probably have me strung up. But what do I care..?

Advertisements

6 Responses to Bool considered harmful

  1. Justin says:

    Dude! what the crap. Why would you say that bools are bad? Foolish? That makes no sense. So the least foolsih would be to add the enums everywhere?

    Dude

  2. Yeah, you’re right. Obviously. Which is why i qualified “never”…
    But still, I’d argue that params should never be bool.

  3. Steven says:

    You can’t just ban booleans as parameters. They are way to valuable and often are just the right type to use. However, if you find Foo(message, true, false, true) unreadable, you can better rewrite the calling code like this:

    bool invert = true;
    bool truncate = false;
    bool trimright = true;

    Foo(message, invert, truncate, trimright);

    or you could just use comments, like this:

    Foo(message,
    true, // invert the message
    false, // don’t truncate
    true // trim right with white space
    );

    or when you like one liners:

    Foo(message, true/*invert*/, false/*no truncate*/, true/*trim*/);

    One of these would be a better rule for your companies coding guideline than banning Bool as parameter from your applications and frameworks.

  4. Steven,
    sure you can re-write the code for the function call to make it easier to read (even when intellisense is not available, i.e. when you print your code).
    But will you do this for every single call ?
    What if Foo is a frequently called method ?
    Well, the first snippet you wrote can be good, but it is quite a bit of boilerplate IMHO.
    The second and the third …
    I believe that Jan’s point is to make the method signature itself explanatory, which consequently makes *ALL* of your calls explained as well, without the need for additional comment in every single place.
    As a framework user, I would definitely prefer a more explicit interface for an API.
    As a framework developer, I think it’s just a little more effort 🙂

  5. […] Jan Bannister escribio este post Bool considerado dañino, donde escribe […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: