Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't use booleans (2019)

luu.io

Post reply on HN
Print view View original

31–40 of 152 posts

Re: Don't use booleans (2019)

#31

Post by kerkeslager »

edflsafoiewq wrote: post #13

Downsides: you have to name and import all the enums (notice no one ever shows this in code examples). You can't do boolean math on them (and, or, etc.).

In most languages with strong types, the IDE will handle imports for you pretty easily. Selecting an import with a hotkey isn't as hard as debugging a mysterious boolean.

Not being able to use logical operations on them is a feature, not a bug: logical operations on unnamed values here are going to be even less readable than passing them into functions.

Re: Don't use booleans (2019)

#32

Post by pavel_lishin »

the__alchemist wrote: post #9

You can think of booleans as a built-in, two-value enum that has a common semantic meaning. Use booleans if this is suitable for your purpose; it will be suitable for many. That said... this article feels like a bit of a strawman. Does anyone by default use three booleans in cases that are arechetypical enums?

My friend, I'd love to give you a tour of our codebase.

Re: Don't use booleans (2019)

#33

Post by asddubs »

bluefirebrand wrote: post #23
happytoexplain wrote: post #15

The assumption being that the language you are using does not have named parameters. Something all modern languages have, except, as usual, the ones the world is built on (JS, Java).

Named parameters are easy enough to mimic in JS using objects and the spread operation function foo({bar, baz}) { ... } foo({bar: 1, baz: false})

that's its own kind of horrible though. now either all your functions just take single object parameters or you have to remember which ones. and I get javascript is light on checking what was passed is actually what was expected but this seems to somehow make that situation even worse still

Re: Don't use booleans (2019)

#34

Post by makeitdouble »

the__alchemist wrote: post #9

You can think of booleans as a built-in, two-value enum that has a common semantic meaning. Use booleans if this is suitable for your purpose; it will be suitable for many. That said... this article feels like a bit of a strawman. Does anyone by default use three booleans in cases that are arechetypical enums?

It usually starts with one boolean.

Then people avoid touching it when expending a bit, so they just add another boolean for the corner case they're dealing with (potentially as an optional last param). And so on, until someone refactors the whole function bearing the burden to retouch all its legacy that accumulated up to that point.

Re: Don't use booleans (2019)

#35

Post by relaxing »

happytoexplain wrote: post #15

The assumption being that the language you are using does not have named parameters. Something all modern languages have, except, as usual, the ones the world is built on (JS, Java).

Having named parameters is such a revelation. And what do we get instead? Added features that make the language more complicated.

Re: Don't use booleans (2019)

#37

Post by kerkeslager »

itotallydont wrote: post #17

fetch( accountId, true, // include disabled, true, // fetch history, true, // fetch details ); typescript saves the day again fetch(accountId: AccountId, options: {includeDisabled?: boolean, history?: boolean, details?: boolean})

That doesn't really solve any but the first problem mentioned in the article.

Re: Don't use booleans (2019)

#38

Post by jmcqk6 »

ervine wrote: post #28
bluefirebrand wrote: post #23

Earlier quoted context omitted.

Named parameters are easy enough to mimic in JS using objects and the spread operation function foo({bar, baz}) { ... } foo({bar: 1, baz: false})

Lemme be an absolute pedant and say that's destructuring, not spreading. And correct me if I'm wrong, nothing worse than an incorrect pedant.

I'm not sure, but I think homicide might be worse than an incorrect pedant.

Re: Don't use booleans (2019)

#39

Post by NegativeLatency »

relaxing wrote: post #35
happytoexplain wrote: post #15

The assumption being that the language you are using does not have named parameters. Something all modern languages have, except, as usual, the ones the world is built on (JS, Java).

Having named parameters is such a revelation. And what do we get instead? Added features that make the language more complicated.

Or the sorta annoying, un-ergonomic builder pattern: https://www.baeldung.com/java-builder-pattern

Re: Don't use booleans (2019)

#40

Post by ervine »

jmcqk6 wrote: post #38
ervine wrote: post #28

Earlier quoted context omitted.

Lemme be an absolute pedant and say that's destructuring, not spreading. And correct me if I'm wrong, nothing worse than an incorrect pedant.

I'm not sure, but I think homicide might be worse than an incorrect pedant.

Well done.
Post reply on HN