Is there any merit to using a nullable bool to store a tri-state value? For example, null == 1st state, false == 2nd state, true == 3rd state
?
The overhead is probably hi开发者_如何学Cgher than using a byte enum, but I'm curious.
You should get a copy of Framework Design Guidelines.
There on page 177 is a chapter Choosing Between Enum and Boolean Parameters.
One of the points there is:
- DO NOT use Booleans unless you are absolutely sure there will never be a need for more than two values.
It's a bit of a subjective question but I'd say no because it would affect readability.
use ?
mark at the end of the type bool which is a struct that contains a nullable bool.
bool? mytristatebool = null;
No
I would recommend to go for Enum as you have already got 3 states in hand now and with scope creep it might increase further. So Enum would be a safe bet and more precise/readable for describing the three states and most important the third state which is neither true nor false.
At the end its more like coding for the eyes who will look latter on to this code and make it meaningful and readable for them
I believe it'd an error doing so.
A boolean is a "two-state" type. This is its definition.
In C#, C++, Java or whatever.
If you want to simulate three states, just implement an enumeration instead of reinventing a square wheel!
If it's a WinForms program, then one possibility would be to use System.Windows.Forms.CheckState. It has values Checked, Indeterminate and Unchecked - which may or may not suit your purposes.
A simpler workaround is to have two boolean variables. One will keep null/not-null and the other will keep true/false
An application of this:
When you are caching a calculation in a boolean property, you need to know if it has been already set or not.
e.g.
// actual variable having true/false
private bool isX = false;
// variable holding wither above is set/not-set i.e. null/not-null
private bool isXSet = false;
public bool IsX
{
get
{
if (isXSet)
{
return isX;
}
else
{
isX = GetX(); // this could be time consuming.
isXSet = true;
return isX;
}
}
}
This become useful in performance tuning when GetX() above is time consuming and IsX is accessed many times.
I would stick to null for unknown or not yet determined. Also you lose the possibility to do math on the values. All in all not a good idea I think
It depends. Great for a property like 'Has Dog': True, False, or we just don't know.
I get why people are suggesting not to use this to represent options A, B and C. I would go with an enum for that too.
But bool? is great for representing an actual boolean value that might not be fetched or generated yet. And no, having a separate bool for fetched is not simpler, it's messier. IMHOP
Now if only C# allowed for local static variables so we could make this fully self contained, like so:
bool isSomething{
get{
static bool? _isSomething = null;
if (null == _isSomething){
_isSomething = goFetchIsSomething();
}
return _isSomething == true;
}
}
But since purists hate readable code the best you can do is this
private bool? _isSomething = null; //Pretty please don't try to use me outside of isSomething
bool isSomething{
get{
if (null == this._isSomething){
this._isSomething = goFetchIsSomething();
}
return this._isSomething == true;
}
}
精彩评论