I’m going to the top of the mountain (cause there’s so many here in Edmonton) and I’m going to shout it loud.  In my little programming world I’m turning into a boolean bigot.  So many things in the world are based on boolean values (day/night, on/off, yes/no) and yet I’m starting to find the use of true/false in code to be meaningless.  I can hear the naysayers all around the world screaming profanities interlaced with my name and that of my sled dog team.  Since none of you will trust me on this, I’m going to have to explain.

People will argue that booleans are necessary to show the state of a more complex time (i.e. Object.Active = true).  If you re-read that last sentence you will notice that the argument is about the use for object state, not whether it is active/inactive.  In this example active/inactive represent the state.  Why wouldn’t we move towards code that used enumerations and would read like this:

Object.State = State.Active

To me there are a number of benefits to the use of an enumerated value set.  For me, this code is clearer when read for the first time.  This is keeping in step with the tenet that all code should read like a book.  It also provides you with the ability to expand the number of states that objects have without ever breaking any code (I’ve seen this done enough to know how painful it is to go from true/false to true/false/somtimestrue).

That last argument is not the strongest one that I can make for using enumerations over booleans.  How about this instead.  Have you ever started to walk through some code that you’ve never seen before and you come across that one function/method call that has 6 parameters, most of which are booleans, and you can’t tell what the heck each parameter does?  Take a look at this code and tell me what the parameters represent.

string SomeStringManipulation(strInput, true, false, true, true, false)

So with your knowledge of that line of code, what does that 3rd boolean (the ‘true’ value) do?  See the problem?  Imagine how this would look in my world full of boolean bigots.  Sigh…fine, I’ll show you an example.

string SomeStringManipulation(strInput, Casing.Sensitive, Capitalization.Lower, Spelling.Check, Grammar.Check, BadWordFilter.Off)

I don’t know about you, but if I were to come across this code in amongst a couple hundred thousand lines of other stuff, I would know straight off what it was trying to do.  It reads much more like proper language (English in this case) than the first example.  That alone should be the litmus test that you use when writing code.  If you can’t read it to someone on the other end of the phone and have them understand what the code is trying to do, you need to rethink how it looks and reads.

The one argument that I can hear a number of people making right now is that each of those parameters are now enumerations and enumerations require more coding.  Well whoopdee-doo.  Tell me that not investing the time up front to use this as a standard was worthwhile once you’re 6 months into a maintenance gig, you have the client breathing down your neck, the code isn’t working, you’ve never seen it before and you come face to face with a list of true/false values.