No. All of this is breaking the primary rule of programming: KISS (keep it simple, stupid). Don't add unnecessary complexity. Avoid premature optimization. Tons of things are correctly booleans and should stay that way.

Turning boolean database values into timestamps is a weird hack that wastes space. Why do you want to record when an email was verified, but not when any other fields that happen to be strings or numbers or blobs were changed? Either implement proper event logging or not, but don't do some weird hack where only booleans get fake-logged but nothing else does.

Should booleans turn into enums when a third mutually-exclusive state gets added? Yes, of course, so go refactor, easy. But don't start with an enum before you need it. The same way we don't start with floats rather than ints "just in case" we need fractional values later on.

Booleans are a cornerstone of programming and logic. They're great. I don't know where this "booleans are bad" idea came from, but it's the opposite of communicating intention clearly in code. That boolean should probably stay a boolean unless there's an actual reason to change it.

A piece of advice I read somewhere early in my career was "a boolean should almost never be an argument to a function". I didn't understand what the problem was at the time, but then years later I started at a company with a large Lua code-base (mostly written by one-two developers) and there were many lines of code that looked like this:

   serialize(someObject, true, false, nil, true)

What does those extra arguments do? Who knows, it's impossible without looking at the function definition.

Basically, what had happened was that the developer had written a function ("serialize()", in this example) and then later discovered that they wanted slightly different behaviour in some cases (maybe pretty printed or something). Since Lua allows you to change arity of a function without changing call-sites (missing arguments are just nil), they had just added a flag as an argument. And then another flag. And then another.

I now believe very strongly that you should virtually never have a boolean as an argument to a function. There are exceptions, but not many.

  copy(obectA, objectB, "")

  engage_turbo_encabulator(True, False, True, False, True, False, True, False)
 

  engage_turbo_encabulator(
    enable_hydrocoptic=True,
    allow_girdlespring=False,
    activate_marzelvanes=True,
    sync_trunnions=False,
    stabilize_panametric=True,
    lock_detractors=False,
    invert_logarithms=True,
    suppress_lunar_wane=False
  )
  

  encabulator = (
    TurboEncabulator.new()
    .enable_hydrocoptic(True)
    .allow_girdlespring(False)
    .enable_marzelvane_activation(True)
    .enable _trunnion_syncing(False)
    .enable_param_stabilization(True)
    .enable_detractor_locking(False)
    .enable_logarithm_inversion(True)
    .enable_lunar_wane_supression(False)
    .build()
  )

    debug_mode=True
    some_func(..., debug_mode)

  copy_from_to_by_key(objectA, objectB, "name")  

  copy_value(
    source=objectA,
    target=objectB,
    key="name"
  ) 

  objectB.set_value_from(objectA, key="name")

    serialize(someObject, { prettyPrint = true })

    Object someObject;
    foo (someObject, Object.Flag1 | Object.Flag2 | Object.Flag3);

    JSON.stringify(val, null, 2);

The scope of TFA is data modelling, where it advises to use more descriptive data values, such as enums or happenedAtTimestamp.

However, personally I agree with the advice, in another context: Function return types, and if-statements.

Often, some critical major situation or direction is communicated with returned booleans. They will indicate something like 'did-optimizer-pass-succeed-or-run-to-completion-or-finish', stuff like that. And this will determine how the program proceeds next (retry, abort, continue, etc.)

A problem arises when multiple developers (maybe yourself, in 3 months) need to communicate about and understand this correctly.

Sometimes, that returned value will mean 'function-was-successful'. Sometimes it means 'true if there were problems/issues' (the way to this perspective, is when the function is 'checkForProblems'/verify/sanitycheck() ).

Another way to make confusion with this, is when multiple functions are available to plug in or proceed to call - and people assume they all agree on "true is OK, false is problems" or vice versa.

A third and maybe most important variant, is when 'the return value doesn't quite mean what you thought'. - 'I thought it meant "a map has been allocated".' - but it means 'a map exists' (but has not necesarily been allocated, if it was pre-existing).

All this can be attacked with two-value enums, NO_CONVERSION_FAILED=0, YES_CONVERSION_WAS_SUCCESFUL=1 . (and yes, I see the peril in putting 0 and 1 there, but any value will be dangerous..)

I’m not a very experienced programmer, but the first example immediately strikes me as weird. The consideration for choosing types is often to communicate intend to others (and your future self). I think that’s also why code is often broken up into functions, even if the logic does not need to be modular / repeatable: the function signature kind of “summarizes” that bit of code.

Making a boolean a datetime, just in case you ever want to use the data, is not the kind of pattern that makes your code clearer in my opinion. The fact that you only save a binary true/false value tells the person looking at the code a ton about what the program currently is meant to do.

This is such a weird advice and it seems to come from a particular experience of software development.

How about using Booleans for binary things? Is the LED on or off, is the button pressed or not, is the microcontroller pin low or high? Using Enums, etc. to represent those values in the embedded world would be a monumental waste of memory, where a single bit would normally suffice.

  enum Bool 
  { 
      True, 
      False, 
      FileNotFound 
  };

I'll expand on the first example, the datetime one.

Many user databases use soft-deletes where fields can change or be deleted, so user's actions can be logged, investigated or rolled back.

When user changes their e-mail (or adds another one), we add a row, and "verifiedAt" is now null. User verifies new email, so its time is recorded to the "verifiedAt" field.

Now, we have many e-mails for the same user with valid "verifiedAt" fields. Which one is the current one? We need another boolean for that (isCurrent). Selecting the last one doesn't make sense all the time, because we might have primary and backup mails, and the oldest one might be the primary one.

If we want to support multiple valid e-mails for a single account, we might need another boolean field "isPrimary". So it makes two additional booleans. isCurrent, isPrimary.

I can merge it into a nice bit field or a comma separated value list, but it defeats the purpose and wanders into code-golf territory.

Booleans are nice. Love them, and don't kick them around because they're small, and sometimes round.

What I'm getting out of this is boolean shouldn't be a state that's durably stored, it's ephemeral, an artifact of runtime processing. You wouldn't likely durably store a boolean in an OLTP store, but your ETL into the OLAP store may capture a boolean to simplify logic for all the systems using the OLAP store to drive decision support. That is, it's an optimization. That feels right, but I've never really thought through this before. Interesting!

The weirdest boolean for me is the "is secure" flag of the web platform, that is true if the site is loaded via https with a valid cert or is served from localhost - and that decides if any advanced browser features are available or not.

It makes sense given the history of the web, but its semantics are pretty much the same as (old) Twitter's blue checkmark.

Both essentially say "the entity you're interacting with is really the one you believe they are" - but neither makes any attempt to actually find out what my belief is, nor do they give me any information to verify that belief myself. It's just a "trust me" in form of a boolean.

Changing a boolean database field like 'is_confirmed' to a nullable datetime is a simple, cheap hack that records a little bit of information about an event. It's appropriate when you're not sure you care about the event.

If you know you actually care about the event, there are probably more fields to stuff into an event record, and then maybe you could save the event record's id instead?

But going too far in this direction based on speculation about what information you might need later is going to complicate the schema.

See Paul's comment in the other thread for more: https://news.ycombinator.com/item?id=44423995

Please if you are in this situation do not take this advice. You just generate massive garbage abstractions upstream. If boolean arguments are out of hand, the problem isn't the boolean.

Strongly disagree with the article. Enums make gradual migrations impossible in both databases and API design with third party consumers. Even in the example they gave where they recommended a user “role” instead of an is_admin boolean they are creating huge problems. Am I supposed to tell all my downstream API consumers that they need to refactor their code because we’re introducing a new value to “role” that covers “billing_manager”? There are literally zero downstream issues with adding is_billing_manager, and you get the additional representation benefit that the booleans can _both be true_, so I am not trapped into an exclusive role paradigm.

Related:

That boolean should probably be something else - https://news.ycombinator.com/item?id=44423995 - June 2025 (1 comment, but it's solid)

APL and its descendents don't have booleans, just 0 and 1 [0]. Which is awesome. It allows for bitmasks, sums / reductions, and even conditionals via Iverson Brackets. [1]

[0] https://aplwiki.com/wiki/Boolean

[1] https://en.m.wikipedia.org/wiki/Iverson_bracket

To summarise: booleans should be derived, not stored

I dont like this pattern.

The author example, checking if "Datetime is null" to check if user is authorized or not, is not clear.

What if there are other field associated with login session like login Location ? Now you dont know exactly what field to check.

Or if you receive Null in Datetime field, is it because the user has not login, or because there is problem when retriving Datetime ?

This is just micro-optimization for no good reason

> A lot of boolean data is representing a temporal event having happened. For example, websites often have you confirm your email. This may be stored as a boolean column, is_confirmed, in the database. It makes a lot of sense.

> But, you're throwing away data: when the confirmation happened. You can instead store when the user confirmed their email in a nullable column. You can still get the same information by checking whether the column is null. But you also get richer data for other purposes.

So the Boolean should be something else + NULL?

Now we have another problem ...

One argument that I’m missing in the article is that with an enumerated, states are mutually exclusive, while withseveral booleans, there could be some limbo state of several bool columns with value true, e.g. is_guest and is_admin, which is an invalid state.

> But, you're throwing away data

Often it’s intentional for privacy. Record no more data than what’s needed.

I generally prefer to let one value mean one thing.

Allowing the presence of a dateTime (UserVerificationDate for example) to have a meaning in addition to its raw value seems safe and clean. But over time in any system these double meanings pile up and lose their context.

Having two fields (i.e. UserHasVerified, UserVerificationDate) doesn't waste THAT much more space, and leaves no room for interpretation.

My preferred framing of this is: "You told me a condition was `true`, presumably because you had evidence for it. Why are you telling me you once had evidence? Just give me the evidence!".

Don't tell me that an event happened; give me the event that happened. (Sure, project it down to something if you like for efficiency; throwing away most of the information is what gives the timestamps example.)

Don't tell me simply whether a user is an admin; tell me what the user is. (That's the enums example.)

Logically speaking, `bool` is equivalent to `Optional<unit>`, and in fact that's frequently what it's used for. Phrased that way, it's much more obvious that this representation doesn't match all that many domains very well; it's clearly useful for performance (because throwing away unnecessary data is a standard performance technique), but it's also clearly a candidate premature optimisation.

The timestamps instead of boolean thing is something good engineers stumble upon pretty reliably. One gotcha is the database might be weird about indexing nulls. I'm not going to give an example because you should really read the docs for your specific database if this matters.

The ever growing set of boolean flags seems to be an attractor state for database schemas. Unless you take steps to avoid/prohibit it, people will reach for a single boolean flag for their project/task. Fortunately it's pretty easy to explain why it's bad with a counting argument. e.g. There are this many states with booleans, and this fraction are valid vs. this many with the enum and this fraction are valid. There is no verification, so a misunderstanding is more likely to produce an invalid state than a valid state.

I read an article with the same premise here a few years ago.

A Boolean is a special, universal case of an enum (or whatever you prefer to call these choice types...) that is semantically valid for many uses.

I'm also an enum fanboy, and agree with the article's examples. It's conclusion of not using booleans because enums are more appropriate in some cases is wrong.

Some cases are good uses of booleans. If you find a Boolean isn't semantically clear, or you need a third variant, then move to an enum.

Oh this is fantastic! I'm giving a talk in about a month at work on how to use the python type system in useful ways to catch more bugs before runtime, and this seems like a great point to throw in there as an aside at the very least!

I once, briefly, worked with a developer who believed that you should never use primitive types for fields or parameters...

Maybe for the DB domain author is talking about but the nice thing about a bool is that it's true or false. I don't have to dig around documentation or look through the code what the convention of converting enum, datetime, etc. to true/false is. 1970/1/1 (I was four years old then, just sayin), -6000 or something else?

Nullable helps a lot here but not all languages support that the same way.

My favorite Java code I've ever seen is:

    @Nullable Optional<Boolean> foo;

For when 3 values for a boolean just aren't enough.

Here are two rules I learned from data modelling and APIs many years ago:

1. If you don't do arithmetic on it, it's not a number. ID int columns and foreign keys are excluded from this. But a phone number or an SSN or a employee ID (that is visible to people) should never be a number; and

2. It's almost never a boolean. It's almost always an enum.

Enums are just better. You can't accidentally pass a strong enum into the wrong parameter. Enums can be extended. There's nothing more depressing than seeing:

    do_stuff(id, true, true, false, true, false, true);

This goes for returning success from a function too.

    enum JsonValue<T> {
        Missing,
        Null,
        Present(T),
    }

I would add counters to this list. Start from zero (false), and then you know not just whether an event has occurred, but how many times.

Aka "Boolean blindness", look it up.

I was hoping to read about bitfields or bit flags.

replace "should" with "could".

I do think its wise to consider when a boolean could be inferred from some other mechanism, but i also use booleans a lot because they are the best solution for many problems. Sure, sometimes what is now a boolean may need to become something later like an enum, and that's fine too. But I would not suggest jumping to those out the gate.

Booleans are good toggles and representatives of 2 states like on/off, public/private. But sometimes an association, or datetime, or field presence can give you more data and said data is more useful to know than a separate attribute.

The only, universally-valid advice is: it depends. There are no hard and fast universal rules except carefully deciding when and when not to break conventions and guidelines.

Depending on the complexity of and user requirements the system, hard-coding roles as an enum could span the spectrum anywhere from a good to a bad idea. It would be a terrible thing if user-define roles were a requirement because an enum can't model a dynamic set of ad-hoc, user-defined groups. The careful and defensive planning for evolution of requirements without over-optimizing, over-engineering, or adding too much extra code is part of the balance that must be made. It could be a good thing if it were a very simple site that just needed to ship ASAP.

Booleans don't "remember" what they mean. They're just a `true` or a `false`, the association with the `is_authenticated` variable or whatever has to be maintained by programmer discipline. But when you have an enum variant like `Authenticated`, that's encoded in the value itself, helped by the type system. It can't be confused with some other state or condition.

Booleans beget more booleans. Once you have one or two argument flags, they tend to proliferate, as programmers try to cram more and more modalities into the same function signature. The set of possible inputs grows with 2^N, but usually not all of them are valid combinations. This is a source of bugs. Again, enums / sum-types solve this because you can make the cardinality of the input space precisely equal to the number of valid inputs.