<< Property Event Pattern | Home | SQL Server Session State Mode over a non-standard port >>

I'm turning into a boolean bigot

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.

posted @ Tuesday, September 12, 2006 12:38 AM

Print

Comments on this entry:

# re: I'm turning into a boolean bigot

Left by Justice~! at 9/12/2006 10:17 AM
Gravatar
The sad thing is that I have read "string SomeStringManipulation(strInput, true, false, true, true, false)" or something close to it *many* times before, almost everywhere I've worked. I thought this sort of evil was well-documented!

# re: I'm turning into a boolean bigot

Left by Mack D. Male at 9/12/2006 10:42 AM
Gravatar
I'm a big fan of enumerations, but... For one thing, I always know what true and false mean. You can always convert it to 1s and 0s. This is useful information, wouldn't you say? Enumerations, on the other hand, can take a variety of values. Despite liking enumerations, I also like simplicity. If something will never have more than two states, why would you introduce a more complex way to represent this? Seems unecessary to me. There's a reason we use base-2 and not decimal or ternary logic in computers! Simple, efficient, and reliable!

# re: I'm turning into a boolean bigot

Left by The Igloo Coder at 9/12/2006 11:19 AM
Gravatar
Mack. I can't disagree with the fact booleans are simple. The simplicity of the selection options (true or false) is decieving thought. The use of booleans to feed function/method parameters actually increases the application complexity by making it less readable. The crux of my argument, which I may not have made very well, is that the increased technical complexity in the data types (using enumerations instead of booleans) is offset by the decrease in complexity for the code readability. For me, the increased readability is much more benefitial than the perceived simplicity of booleans. We read our code much more than we ever write it. As soon as you write the code for the first time, you are destined to read it forever, but you most likely will not revise it more than a handful of times. Because I'm going to be reading my, or other's, code much more often than I will be revamping it, I put a much higher weight on readability. I don't understand your argument for the ability to change booleans from true/false to 1/0. This was a huge issue for people who wrote code in VB6 and had to migrate to .NET. In VB6 the values for true/false were -1/0 and this didn't map to .NET's 1/0 mantra. Not only that, but I can't establish a good reason that a business application would find a boolean to integer conversion useful. I'm sure they exist, but they are the exception not the rule. When you boil it right down to the pulp, booleans are nothing more than a two value enumeration which have been assigned the values 0 and 1. If you think of it this way, why not make use of enumerations, with 2 or more values, so that the code is much more readable.

# re: I'm turning into a boolean bigot

Left by JH at 9/12/2006 12:54 PM
Gravatar
If you introduce enumerations instead of booleans, you allow future developers to add in their own (possibly unintended) items into your code, making it less readable or even cause your previously written code to break. e.g. // Intending a boolean time of day public enum TimeOfDay { Day, Night } An unassuming developer in the future might feel free to add an enumeration (say, "Morning" [somewhat legitimate addition], or "Carrot" [definitely unintended]) that the code you wrote, intending to only ever use the binary "Day" or "Night", to (possibly) no longer work properly (depending on how you wrote your code). e.g. //This code is resiliant to the change public void DoSomething(TimeOfDay timeOfDay) { if(timeOfDay == TimeOfDay.Day) { //Do something } else if(timeOfDay == TimeOfDay.Night) { //Do something else } } e.g. //This code may not be as resiliant to the change public void DoSomething(TimeOfDay timeOfDay) { if(timeOfDay == TimeOfDay.Day) { //Do something } else { //Do something else //If this code does anything under //The assumption that it is night //It will break in the future. } } Boolean True/False puts a finite number of conditions. In this type of example, I think that if you intend to only ever have two possibilities and only two possibilities, you should choose to "saccrifice" readability (I don't agree that it is less readable) to improve the long-term stability of your application.

# re: I'm turning into a boolean bigot

Left by Tom Opgenorth at 9/15/2006 1:18 PM
Gravatar
FWIW, many moons ago, in an educational institute not so far away, I was taught by a wise instructor that flags (booleans) were evil and had no use. I thought he was a quack. Now that I'm old, I notice that code eventually gets refactored to enumerations over time for a lot of things. I too am a boolean bigot I guess (and I do always keep an eye on UInt32's as well - the filthy buggers).

# re: I'm turning into a boolean bigot

Left by Kenneth LeFebvre at 9/25/2006 6:57 PM
Gravatar
I agree that using enums is good. I wouldn't use one if I knew that my value would always be only one of two (or three, if nullable). So, object.IsEnabled should be a bool, in my opinion. There's never going to be another way to answer the questions "Is my object enabled?" than with a yes or no answer. However, I generally tend to make my boolean properties read-only, clearing away StringManipulation arguments (bad pun, I know). I also agree with Steven[1], when he suggests you shouldn't be using so many arguments in your method! In my opinion, your source code should aim for maximum readability by humans (thus, enums are good); code generation and good compilers are the better way to deal with runtime performance and resource inefficiencies (a common argument in favor of using boolean values, in my experience, is that they are more efficient). As far as JH's comment about enums goes, that scenario can only happen if you're sharing source code, not assemblies. Good versioning practices prevent shared assemblies from falling into such a pitfall, whereas source code reuse is an entirely different "good vs. evil" topic for discussion! Just my two cents...

# re: I'm turning into a boolean bigot

Left by Kenneth LeFebvre at 9/25/2006 6:58 PM
Gravatar
oops! I meant to provide the link to Steven's comments: [1] http://www.stevenrockarts.com/blog/PermaLink,guid,bc8a7b6a-2933-4c56-9199-0d7ac11bee9f.aspx

Your comment:



 (will not be displayed)


 
 
 
Please add 5 and 1 and type the answer here:
 

Live Comment Preview: