October 28, 2005
Brad Abrams recently posted another great excerpt from the unfortunately named .NET Framework Standard Library Annotated Reference Volume 2:
Avoid creating methods with Boolean parameters. Boolean parameters make calls harder to read and harder to write.
Indeed. What is the difference between..
Who knows? I've certainly made this mistake before. The SLAR recommends ditching the boolean in favor of an enumeration:
Voil. Self-documenting code. If you're not careful, boolean parameters become magic numbers.
Avoiding boolean parameters isn't a new idea, of course; similar advice is dispensed by C++ guru Herb Sutter in this 2002 C++ User's Journal article. What you may not realize, however, is that it's also a good idea to avoid booleans in your user interface. Jef Raskin explains in his book, The Humane Interface:
Check boxes can leave the user guessing what the alternative is. For example, if a check box labeled "Save to archive on closing" is checked, the data will be saved to an archive when the window is closed, but the label gives little clue as to what will happen if the box is not checked. Will the data be saved somewhere else, not saved at all, or will another option appear when you close the window? Often, the best solution is to use a set of radio buttons; they are not modal, and the user can clearly see not only the current state but also the alternative(s). Whether checkboxes or radio buttons are used, it is important to label with adjectives which describe the state of the affected object. If verbs are used as labels, the user does not know whether the action has taken place or is yet to take place.
For one-of-many choices, radio buttons are already the standard, and there is rarely any reason to use other mechanisms. Whenever possible, use radio buttons instead of checkboxes. Checkboxes work reliably only when the value of the state controlled by the check is immediately visible or in short-term memory.
As a developer my go-to boolean UI element is the checkbox. If it can be true or false, it's a checkbox, right? Like so:
But what does the verb "Lock" mean? This checkbox violates the Don't Make Me Think rule. Now watch what happens when we change to adjectives and radio buttons:
This is conceptually identical to the code sample; we simply switched from a boolean to an enumeration. It's amazing how obvious the benefits are in retrospect, but it sure wasn't obvious to me. Until today.
Posted by Jeff Atwood
Booleans as parameters are just a special case of avoiding "magic numbers," period, perhaps -- ? For the most part this is now standard practice (e.g., the values you can pass to, say, File.Open), although your entry points out that this "don't make me guess what the value means" extends to anything -- maybe even strings. (?)
I agree with Stephan that it's not a matter of "don't use booleans in the UI," but rather of how well they're presented to the user. It's useful advice, tho, to bear in mind that a boolean is asking a question ([ ] Send information via email) and that, as you say, the designer should be aware of the "What happens if I uncheck this?" scenario.
Amen, brother! I only recently realized the same thing (booleans should always be enums) for interfaces:
The only unfortunate thing about using radio buttons is that they take up more space. Too bad we don't have a standard UI element that can show both states with labels, but in the same space as a checkbox.
Booleans in the UI should stay boleans, so I beg to differ. However you have a valid point: if you have a single checkbox and the sentence is not clearly yes/no then a (radio button) enumeration is clearly superior. If the Radio button is labeled yes/no it is clearly a boolean and a checkbox will do just fine (see this comment form :-) ). Also when you have a group of yes/no answers checkboxes are superior to radioboxes e.g
 Menu 7
Burger with Coke
 Salad 2.00
 Soup 0.50
 Ice Cream 1.00
So as usual it depends.
Booleans can also be used in manner similar to enums, if you previously define these values, i.e. (C++)
#define LOCKED true
#define NOT_LOCKED false
This is how I use them all the time...Simply passing "true" or "false" as a value to a function makes the code very unreadable.
Definitely some good points. I agree in theory, but in practice the thought of coding all those enums, and then having to deal with all their namespaces, makes me shudder. Maybe I'm just taking that adage about good programmers being lazy a little bit too far.
Also, since we're talking about code style, I think it's generally accepted that function names should be verbs. So what's with this Authorization() function you've got Jeff? Tsk tsk tsk... ;)
what's with this Authorization() function you've got Jeff?
Hey, it's taken from the SLAR example, not my code.. all my functions are named after favorite colors.
I completely agree that boolean parameters should be avoided. I've been using enums since I can remember, and get quite annoyed when I find other people haven't been bothered to spend the 20 seconds it takes to add an enum.
The .NET framework has many methods which take boolean parameters. Intellisense can tell you what they mean as you're about to enter them, but that doesn't help you later when you're reading the code. VB.NET supports named parameters, so you can put your documentation in working code. With C#, I suppose you have to resort to a /* comment */.
IO.Directory.Delete("c:\", true /* recursive */)
Indeed, this style of user interface gives more information and thus is easier to understand and use.
Damn! I am using booleans in my current project right now...just like the example. I didn't even have clippy popping up, "It looks like your trying to write crappy code....".
You know, the bools are easy to understand when you are using a tool like visual studio. Even still, I'm off to code up some enums.
I worked for the State of Maine for a little while. Part of my job was working with a department to ensure that our application was usable via a screen reader (for the vision impaired). One of the things we did was remove most of the checkboxes, since many screen-readers can't handle them that well. In some cases, they don't handle radio buttons either... you should use a list box (single select to replace radio buttons and multi-select to replace multiple checkboxes).
I've found drop-down listboxes to be a space-saving and better-looking alternative to radio buttons.