Brad Abrams recently posted another great excerpt from the unfortunately named .NET Framework Standard Library Annotated Reference Volume 2:
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:
https://nedbatchelder.com/blog/200507/booleans_suck.html
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
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:\", Recursive:=True)
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.