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

41–50 of 152 posts

Re: Don't use booleans (2019)

#41

Post by asddubs »

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 "is_car", a simple, clear, yes or no. and then at some point someone needs to also check if it's a sedan and instead of turning it into an enum called vehicle_type an "is_sedan" is added, etc.

Re: Don't use booleans (2019)

#42

Post by relaxing »

0x63_Problems wrote: post #4

I'm definitely a fan of making bad data 'unrepresentable' through the type system. The bit flag enum pattern is not so familiar to me in Python, but I recognize it from the CPython internals so maybe it's more common in systems languages. Not sure how I feel about explicitly listing every valid combination of flags, but I'm sure in some cases that's the right move.

In Python you can use keyword arguments to the same benefit.

Re: Don't use booleans (2019)

#47

Post by wrs »

edflsafoiewq wrote: post #24
kierenj wrote: post #5

Solution in C#: use named parameters: RaiseInvoice(taxInvoice: false, sendEmail: true)

If you don't have named parameters, you can fall back to variables var taxInvoice = false var sendEmail = true RaiseInvoice(taxInvoice, sendEmail) It's obvious, but people tend not to do it.

Sadly there is nothing that can tell you that you got those arguments backwards.

Re: Don't use booleans (2019)

#48

Post by HumblyTossed »

keithnz wrote: post #44
kierenj wrote: post #5

Solution in C#: use named parameters: RaiseInvoice(taxInvoice: false, sendEmail: true)

no, way better to make an options object then set the options you want, also works a lot better later when you want more options.

Way better use a bit pattern.

Re: Don't use booleans (2019)

#49

Post by happytoexplain »

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})

I'm aware, but "mimic" is the key word here. Other languages are named-first. E.g. in Swift nobody is thinking "should I name this parameter?". They name it by default, because they have to choose an internal name anyway, and they only reach for the anonymous-parameter feature after explicitly considering "should I make this parameter anonymous?"

In other words, this blog post is practically irrelevant to those languages.

Re: Don't use booleans (2019)

#50

Post by klyrs »

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.

Is the so-called victim the pedant in question?
Post reply on HN