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

141–150 of 152 posts

Re: Don't use booleans (2019)

#141

Post by camgunz »

I feel like this comes up here and there, and generally what I think is these probably aren't good functions. Enums won't save you from all the twisting and turning you're doing in a function that takes 3 booleans.

Rules like this aren't that useful IMO. What if you have like a SetActive(bool active) method? Does this also get an enum? Should this be two methods? Blah blah blah. You can only cultivate taste with experience and consideration, not with rules. Everyone's seen codebases that followed all the rules but were still total messes. Or as Tool said: think for yourself; question authority.

Re: Don't use booleans (2019)

#142

Post by yellowapple »

camgunz wrote: post #141

I feel like this comes up here and there, and generally what I think is these probably aren't good functions. Enums won't save you from all the twisting and turning you're doing in a function that takes 3 booleans. Rules like this aren't that useful IMO. What if you have like a SetActive(bool active) method? Does this also get an enum? Should this be two methods? Blah blah blah. You can only cultivate taste with expe…

> What if you have like a SetActive(bool active) method? Does this also get an enum?

I'd be inclined to do away with the argument entirely, instead going with separate SetActive() and SetInactive() methods.

Re: Don't use booleans (2019)

#143

Post by hardwaresofton »

c-hendricks wrote: post #133
hardwaresofton wrote: post #74

Earlier quoted context omitted.

Ah I love Typescript (IMO JS is the best "scripting language" out there, and has been for a very long time, but that's a different discussion). That said, I hate that typescript has many ways of doing it. That's the biggest problem. There's: enum SomeEnum { First, Second, } const enum SomeConstEnum { A = 1, B = A * 2, } type SomeEnumType = "first" | "second"; const SomeObjectThatIsAnEnum = { "first": 1 "second": 2 }…

I've done things like this before: https://www.typescriptlang.org/play/?#code/PTAEAkFMBsAdIE4Gc... The gist is: define your enum values as a const array. Then you can generate a TypeScript type based on whatever values you have in there. And, since it's an actual array, you can easily write guards / asserts. So you end up with something easy to extend and also has compile-time and run-time checks.

Thanks for the snippet, it is INTENSE. Will see what I can learn from it — const array I definitely didn’t consider before!

Re: Don't use booleans (2019)

#144

Post by kerkeslager »

edflsafoiewq wrote: post #139
kerkeslager wrote: post #132

Earlier quoted context omitted.

I'd actually go further and say that there's no reason I can think of that foo() shouldn't have access to the ScrubbingOption, so just pass that in. If you have two-option enums and for some reason you transform them into two-option enums that represent essentially the same thing, of course that's going to be unnecessarily complex. As a general rule, "it's more verbose" isn't much of a concern to me: verbosity is a v…

> If you have two-option enums and for some reason you transform them into two-option enums that represent essentially the same thing, of course that's going to be unnecessarily complex. "For some reason" being anything so prosaic as they come from different libraries.

If you have two libraries that aren't explicitly made to work with each other and operate on the same problem domain, being explicit about the translation layer between those two libraries is very much a feature, not a bug. That's absolutely a spot where verbosity and named enums will shine.

Re: Don't use booleans (2019)

#145

Post by nivertech »

hardwaresofton wrote: post #67

Tangentially -- use languages that have great enum support. Well you knew what was coming -- Rust enums are excellent[0], and so are Haskell's[1] (try and spot the difference between an enum and a record type!)... But that probably won't help you at $DAYJOB. A bit more on topic though -- I'd like to see a strong opinion on Option versus SomeEnum containing a Missing variant. I usually lean towards Option but I wonder…

Option/Maybe/Result is a Boolean in disguise.

It has the same problem as Booleans by supporting only two branches: single happy path and single unhappy path, when real life may have many paths, and it’s not always clear which of them are happy or unhappy (from the business logic point of view).

Even for purely technical errors, simple OK | ERROR isn’t enough, but should be something like OK | RETRY | UKNOWN_ERROR | FAILED.

Re: Don't use booleans (2019)

#146

Post by hardwaresofton »

nivertech wrote: post #145
hardwaresofton wrote: post #67

Tangentially -- use languages that have great enum support. Well you knew what was coming -- Rust enums are excellent[0], and so are Haskell's[1] (try and spot the difference between an enum and a record type!)... But that probably won't help you at $DAYJOB. A bit more on topic though -- I'd like to see a strong opinion on Option versus SomeEnum containing a Missing variant. I usually lean towards Option but I wonder…

Option/Maybe/Result is a Boolean in disguise. It has the same problem as Booleans by supporting only two branches: single happy path and single unhappy path, when real life may have many paths, and it’s not always clear which of them are happy or unhappy (from the business logic point of view). Even for purely technical errors, simple OK | ERROR isn’t enough, but should be something like OK | RETRY | UKNOWN_ERROR | F…

Yup, definitely a case for enums there -- I don't think the rule is absolute (I'm not sure you should always use enums over booleans), but much of the time it seems to be true.

Re: Don't use booleans (2019)

#147

Post by kazinator »

yen223 wrote: post #115
CoastalCoder wrote: post #110

Earlier quoted context omitted.

Is this an example from some well-known compiled language? I work mostly in C++, and this is a feature I've wished for for a long time.

Kotlin does this https://kotlinlang.org/docs/functions.html#named-arguments

Nope!

> "When you use named arguments in a function call, you can freely change the order that they are listed in."

That violates a key requirement in my specification, which means that I regard it as broken.

Positional parameters should take arguments only in their designated argument position.

Only non-positional parameters (keyword parameters) should be allowed to be specified in any order.

Re: Don't use booleans (2019)

#148

Post by sebastianconcpt »

Quothling wrote: post #65
sebastianconcpt wrote: post #52

Tell me you're almost ready for Rust without telling me you're almost ready for Rust.

You're not wrong, but you're probably getting downvoted because you didn't elaborate on what you mean. Possibly also because the way Rust handles structs isn't exactly unique to rust. Go does it, Typescript does it, and so on.

Happy to elaborate. Although I was having enums in mind https://www.youtube.com/watch?v=Epwlk4B90vk

Re: Don't use booleans (2019)

#149

Post by camgunz »

yellowapple wrote: post #142
camgunz wrote: post #141

I feel like this comes up here and there, and generally what I think is these probably aren't good functions. Enums won't save you from all the twisting and turning you're doing in a function that takes 3 booleans. Rules like this aren't that useful IMO. What if you have like a SetActive(bool active) method? Does this also get an enum? Should this be two methods? Blah blah blah. You can only cultivate taste with expe…

> What if you have like a SetActive(bool active) method? Does this also get an enum? I'd be inclined to do away with the argument entirely, instead going with separate SetActive() and SetInactive() methods.

>> I'd be inclined to do away with the argument entirely

> Should this be two methods? Blah blah blah.

Re: Don't use booleans (2019)

#150

Post by JamesonNetworks »

kazinator wrote: post #147
yen223 wrote: post #115

Earlier quoted context omitted.

Kotlin does this https://kotlinlang.org/docs/functions.html#named-arguments

Nope! > "When you use named arguments in a function call, you can freely change the order that they are listed in." That violates a key requirement in my specification, which means that I regard it as broken. Positional parameters should take arguments only in their designated argument position. Only non-positional parameters (keyword parameters) should be allowed to be specified in any order.

Is there an example you have in mind as to why the params, if passed via keyword, would need to stay in their position? It sounds like external calls made to the internal api without the headers being present? Trying to understand why the position/order would matter to you once arguments are named?
Post reply on HN