It’s quite common to have Yes/No answers in a form.
What’s the best way to represent these? Well, a binary
answer like that maps best to a boolean, right?
True, but what about null?
There’s two possible ways in which we might use a null.
It could represent a N/A or Don’t Care response to the
question. I don’t think this is a valid use of null however.
Null should mean there is literally no value for this yet. So if
we view this field in the DB, and we see a null, we can
take it to read ‘this has not been answered’.
So if we want a N/A option, I don’t think we should be using a bool.
We should have an enumerated type of some kind at this point.
OK so what input element do we use? Maybe a checkbox. Well,
this only gives us two possible scenarios – checked and unchecked.
And we have no way of differentiating between unchecked and null.
If the checkbox is unchecked, is that because the user wants to
select false, or is it because they simply haven’t answered this
So we can use radio buttons. One radio for yes, one for no. And
if the user hasn’t answered the question yet, then neither yes or
no is checked.
we have a nullable bool?
Because the response to something may currently be unanswered.
We can’t assume that because it is null that that means true or false.
One possible option is to have 3 radio options – one meaning
yes, one meaning no, and one meaning something like N/A or Don’t Care.
It might work in some cases (what cases?), but in our case, N/A or
Don’t Care is not a valid answer. Null means this question has not
yet been answered.
Does null mean a 3rd option, such as N/A?
No, it means unanswered. So we don’t want a 3rd option.
What we want is Yes and No radio buttons, and then for neither
of them to be selected if the user has currently not answered.
What kind of branching strategies are we looking at?
We want something for when we do a release.
Having a branch for a release seems like a no-brainer.
We’ve got a snapshot of all the code and its dependencies at
the time of release. So we can roll back to it for that given
Let’s call these RELEASE BRANCHES.
And also something so that we’re not tripping over each others’ code.
Let’s call these FEATURE BRANCHES.