Hacker News Reader

Comment by nerdponx | Hacker News Reader

The thing about boolean flags is interesting. My gut reaction was that it was highly questionable as a general principle, because you might have several such flags and you don't want to make a separate function for every combination.

But in a case like this, where a flag or enum is dispatching between two distinct code paths, maybe it's worth considering separation into distinct functions.

View on HN

This is a Hot Take (tm) that I havent fully considered so grains of salt etc, but boolean flags are in essence bad product type. Given a function

  create(entity, bool_a)

we have a function that creates an entity and take a bool flag, and it has 2 possible variants (entity + true, entity + false). If we add another bool flag

  create(entity, bool_a, bool_b)

then it increases to 4 states. Add another and you're dealing with 8 states, and so on and so forth. We likely don't care about all 8 states - rather 4 or 5, but complexity increases.

In this case, with the type key, we're essentially dealing with a sum type that has two variants

  (admin, attributes) | (customer, attributes)

which is fairly clear. if we add another variant to it, we only increase by one

  (admin, attributes) | (customer, attributes) | (distributor, attributes)

This is the problem with blog articles showing minimum code examples. Minimum code examples are important because the more code you show the more your audience spaces out and moves on. The comments here are saying "but you just moved it to somewhere you didn't show", but it's the nuance in this comment that really gets to why this can be valuable.

> We likely don't care about all 8 states - rather 4 or 5, but complexity increases.

When you have only 2 valid use-cases, you need the code for both. It has to exist. When you have 5 valid use-cases and 3 invalid use-cases, making those 3 invalid use-cases impossible leads to better maintainability. So the minimum code example isn't actually the minimum code example to show why it is effective.

And yeah, product types and the ability to ensure that if you don't handle a case that is possible you get a compiler error is clearly the ultimate result the blog author is searching for.

I agree that in this particular example of creating an instance of an entity, it's bad. It doesn't even make sense, like something you would set up as a strawman in a post about being too DRY.

What would be the point? To try and ensure that certain setup measures are taken in all cases?

Do people actually write code like this? Maybe this is a programming language culture difference, but I never see this pattern in my Python work, professional or otherwise.

I think my issue is that this post takes a very narrow view of what Boolean flags are used for. I would hope that they are not advocating against things like `fetch(url, verifySsl = false)` !

In Python libraries (pyyaml, for example), occasionally you’ll come across a pair of methods named something like `load` and `load_safe`.

For the example you gave, I think it’d be a much better design to have `fetch` and `fetchNoVerify` because this would make it much easier to audit the code to see if SSL verification is ever skipped.

Reply on news.ycombinator.com