Hacker News Reader

Comment by johnlbevan2 | Hacker News Reader

Maybe we need nullable checkboxes; so you have to explicitly make a choice either way, rather than leaving things to default.

- If you have to opt in, most people won't bother as it's not of direct benefit to them (even though overall it's beneficial to the community the more people who do opt in).

- If you have to opt out, people will complain even where the option's made explicitly clear (i.e. where it's not an attempt at being devious / a deliberate dark pattern).

Admittedly then people complain that they have to make a choice / can't just install-and-go... :/.

View on HN

An off-topic mention, everytime I think of a project I'm taking over and seeing "nullable booleans" I'm left wondering why the developer before me went with that approach, there's no commentary as to why nor do I see any indication of nullable booleans being used in any special way / case.

Can any dev out there give me a good use-case aside from forcing someone to check something, and should nullable booleans mostly make sense on front-end as opposed to back-end code? How does a GUI define something is nullable, if a user has not selected it but it's unselected by default.. I find it all a bit confusing...

A checkbox is the wrong UI control for this, because its two states (checked and unchecked) do not cleanly map to the three possible values (true, false, no value).

Radio buttons come closer, but most UI widget libraries provide no way to select none of a radio group once one has been selected. So you can have a radio button each for true and false, and default to no value (i.e. neither selected), but the user can't change her mind and go back to no value.

Sometimes that's okay, as when no value is invalid or meaningless in the context of the form. When it's not, the best solution I have is a select box with three options; three radio buttons in a group would work too from a semantic perspective, but necessitate a probably confusing label on the no-valued one, where a blank option in a select box is much likelier to make intuitive sense to the user, especially if it's the default.

For required fields, either works. With the select box, making the no-valued option default requires the user to interact with the field, and the same holds for a radio button pair that has no button selected by default. In either case, if the field's value is null rather than false, you know no selection was made and can complain accordingly.

>A checkbox is the wrong UI control for this, because its two states (checked and unchecked)

Windows developers might disagree, since Windows 95 checkboxes have had three states (on/off/mixed, or checked/unchecked/filled out), and the third state is used in a lot of places by Windows (though usually to mean that some subitems are on and some are off).

I've never seen one of those used to represent a null value, and I'd consequently avoid using one that way purely on the principle of least surprise.

Sometimes you need to know if a value has been explicitly defined or not. Also, sometimes you need to know if a value is different from what it was before. Nullable values help in both cases, because you can tell the difference between the "default" value (false for boolean, "" for strings, 0 for numbers) and "no" value (null). If you have a form being submitted, you can tell the difference between the user setting fields to their default vs the fields not being returned to you at all.

Another example is an ORM system. A data entity could be initialized from an existing database record, or it could be blank. Each property of the data entity could be initialized or not, depending on the SQL query that was used to initialize it. For fields that are non-nullable in the database, you can compare two entities for the same record to determine if fields have been updated or just weren't initialized. That lets you perform database updates only when necessary, and prevents accidentally deleting information.

All booleans - in the fullness of history, brought into the harsh light of business logic - are destined to become enums.

That's deep and thought-provoking. I like it!

One of my clients has a database flag field that I needed to use to determine whether or not to show something on their website. Should be a simple boolean field, I thought. Nope; their field can contain one of half a dozen character codes, none of which are Y or N. So you're right; I created an enum to represent the allowed codes and map them to meaningful names, and then I had to create a second boolean property to contain the business logic that decides whether or not to do the display based on the various codes.

Here's a use case for nullable booleans in the database, at least. Arguably this could be solved with different data modeling, but suppose you have an "Application" model/table that represents an employment or credit application. The application requires many different steps, so you want to save progress along the way. On Step 3, there are checkboxes for perhaps certifying whether or not you're a U.S. Citizen, or to check if you agree to a certain legal document. Prior to step 3, you wouldn't want to default those values to "false", as they haven't been specified yet by the user, so you leave it as "null". Once the user saves Step 3, you can now be sure that the false or true value is one that came from the user.

That being said, I challenge other developers on my team to make sure they have a very good reason for using a nullable boolean. Sloppily using nullable booleans when not needed causes queries and data understanding to be a mess (i.e. what does IsActive == null mean?!), as well as the possibility of introducing subtle bugs.

Also, I don't think "nullable boolean" as used by the parent actually should refer to the CLI/GUI, but rather that the setting of whether you've opted in or out would be null by default before the first run, and then the CLI/GUI would force a choice resulting in a non-null true or false for whether to opt-in to telemetry. That doesn't require "nullable" checkboxes, but rather a nullable boolean data field in the .NET Core settings. If you need to represent a "I'm purposefully not making a choice" null boolean value in a UI, use a radio group with 3 options.

I know this is an example, but I would also say please do not store things that you dont know yet.

Eg, if there is a form with optional values, do not store them in a sparse row, instead consider using Entity Value Attribute to store each value as a row (even though its kind of blegh in general, you wont ever store nulls for things you just dont know "yet".)

Reply on news.ycombinator.com