True or False..........or Unknown
I was reading an article on Wikipedia a couple of days ago and clicked on a link in the article. I was brought to this page and figured I would post it seeing all of the True, False and File Not Found Boolean comments on the board. I don't know why a Unknown Value wouldn't be classified as false but there is probably many good reasons for that.
C# supports nullable types as of version 2.0; that is, you can use:
- where b might or might not have a value (b.HasValue is true, so check b.Value) or might be null. Useful for, yes, databases that return true/false/null.
There's usually a sane reason for this sort of thing. Sex M/F could also have the value null if not populated.
Because an unknown value should not be generically considered false.
Basically, any value that should be a pure true/false value could have an unknown or null value associated with it. When this happens you should be able to assume either true or false. For example, you have shipping addresses with a flag of Validated, if the flag is NULL you can assume false. If on the other hand you decided to name the flag InvalidAddress then you have to look at your business rules; you can assume either a true false value, but your rules will determine which one you set.
In the case of values that are not pure true/false values you should not be using a boolean, but rather an enumerator. This handles the case of a field called Male in a table. People think this is true or false, but what happens when it is not provided? Is it safe to assume female? What about Male? We all know this is a flawed design and should instead be called gender using an enum with Male, Female, Undisclosed, etc...
Oh and the page you linked to, totally WTF material.
Read my previous posting and you will realize this is code trying to fix bad design. So WTF code to fix WTF design equates to WTF applications and patterns. Don't ever do what they are proposing unless the design is permanently set in stone.
Ignoring the specific boolean True/False/Null case, I still think nullable types are a good idea (and so can be extended to, yes, booleans). Rather than have to give each new type a new 'magic' unset value (Male/Female/Undisclosed) I'd much rather use the built-in one, null.
Basically, any value that should be a pure true/false value could have an unknown or null value associated with it. When this happens you should be able to assume either true or false.
If you had an "age" field on a database, how would you record an unset value - 0? -1? I'll stick to using null.
I am not saying nullable types are bad. It just that when looking at booleans, the nulled value should or rather be required to be able to be assumed one or the other safely, otherwise it isn't really a boolean value.
In the case of the gender, you can use just two values, but you actually have three which is undertermined, once you go beyond two you really don't have a boolean value.
In the case of age, you can make a non assumption when you have a null and that is to not display any value. Ages are different from either an enum or a boolean.
The OP linked to an article talking about booleans and when you think of it in this fashion then nullables that can not be assumed either true or false are no longer booleans but rather an enum. To put it in perspective, when you have three possible values how do you do this:
Booleans by definition require them to be bi-state and only bi-state, anything else is a three value enumerator. If you have a null value you need to safely assume one of the two states like I mentioned before. Even in this case you can use nullable values but in working with the data you assume one or the other. Like a Validated field, it is boolean, but if it is Null you assume false. Any other usage of a boolean is wrong, it is basic computing theory.