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

131–140 of 152 posts

Re: Don't use booleans (2019)

#131

Post by xigoi »

presentation wrote: post #25
_fat_santa wrote: post #7

Tangential but coding in JS/TS, I often will go for object arguments to make things more readable. If you have a function like: foo(arg1: boolean, arg2: boolean, arg3: boolean) Then when you call it it will look like foo(true, false, true) which is not great for readability. Instead I move all the arguments into an object which makes each field explicit. Ie. foo({ arg1: true, arg2: false, arg3: true }) This also carr…

You can actually set up VSCode and probably other editors to show the parameter names inline with the values.

I hate inlay hints because they usually add unnecessary clutter. I prefer to use languages that allow you to add them manually when needed.

Re: Don't use booleans (2019)

#132

Post by kerkeslager »

oneeyedpigeon wrote: post #81
edflsafoiewq wrote: post #51

Earlier quoted context omitted.

Think about cases more complicated than passing a bare literal. // Booleans + Named Parameters foo(should_scrub=not options.scrubbing_disabled) // Single-Use Enum import ScrubbingOption, ShouldScrub; foo( if options.scrubbing == ScrubbingOption::Disabled { ShouldScrub::No } else { ShouldScrub::Yes } )

If you format the second example more sensibly: foo(options.scrubbing == ScrubbingOption::Disabled ? ShouldScrub::No : ShouldScrub::Yes) it doesn't look much worse at all

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 very poor indication of complexity, and entering code with your keyboard simply isn't the bottleneck for writing code (if it is, you aren't thinking about what you're writing enough).

Re: Don't use booleans (2019)

#133

Post by c-hendricks »

hardwaresofton wrote: post #74
teaearlgraycold wrote: post #70

Earlier quoted context omitted.

Typescript is great for this. function operation(user: User, state: “active” | “inactive”): void Boom. Done. Enum defined. You want people to use enums? Remove all context switching from the definition process.

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.

Re: Don't use booleans (2019)

#134

Post by smitty1e »

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…

Python's enum support[0] seems quite comprehensive, as well.

The nice thing about a class is that when some bizarre edge case comes up (and whose Extract, Transform, Load process has not?) one can isolate the weirdness.

[0] https://docs.python.org/3/library/enum.html

Re: Don't use booleans (2019)

#135

Post by wk_end »

wavemode wrote: post #121
CoastalCoder wrote: post #111

Earlier quoted context omitted.

I've wanted a similar thing for C++. Anyone know what the reasons have been for the language not adopting this?

It would cause argument names to become part of the function signature, which would be a significant change to the language, and its ABI.

Wouldn’t you be able to treat this as syntactic sugar - effectively you rearrange the arguments as needed and strip the labels. Doing that wouldn’t necessitate any kind of change to the ABI, I think.

Re: Don't use booleans (2019)

#136

Post by griftrejection »

asddubs wrote: post #41
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.

Can't developers just... not do that? You can write bad code in any language. What is our responsibility as experts to avoid doing things like this, then?

Re: Don't use booleans (2019)

#137

Post by Gibbon1 »

wk_end wrote: post #135
wavemode wrote: post #121

Earlier quoted context omitted.

It would cause argument names to become part of the function signature, which would be a significant change to the language, and its ABI.

Wouldn’t you be able to treat this as syntactic sugar - effectively you rearrange the arguments as needed and strip the labels. Doing that wouldn’t necessitate any kind of change to the ABI, I think.

Yes it's basically designated initializers for function arguments. Interestingly designated initializers got added to C99 and then WG21 sat on their finger for 20 years before adding it to C++.

It can't be anything but the most trivial thing to implement.

Re: Don't use booleans (2019)

#138

Post by teaearlgraycold »

hardwaresofton wrote: post #96
ikekkdcjkfke wrote: post #89

Earlier quoted context omitted.

Typescript type system is probably gold standard, you can enforce so much statically

As far as gold standards go for typesystems... ML languages probably take it, with Haskell being the closest to widespread real world use.

It's the gold standard for languages you'll be able to use at work.

Re: Don't use booleans (2019)

#139

Post by edflsafoiewq »

kerkeslager wrote: post #132
oneeyedpigeon wrote: post #81

Earlier quoted context omitted.

If you format the second example more sensibly: foo(options.scrubbing == ScrubbingOption::Disabled ? ShouldScrub::No : ShouldScrub::Yes) it doesn't look much worse at all

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.

Re: Don't use booleans (2019)

#140

Post by asddubs »

griftrejection wrote: post #136
asddubs wrote: post #41

Earlier quoted context omitted.

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.

Can't developers just... not do that? You can write bad code in any language. What is our responsibility as experts to avoid doing things like this, then?

if they know better and have the foresight, they do. But stuff like this might not occur to people who've never been bitten by it. Every step of the way you just make things a little bit messier than before.
Post reply on HN