Live data from Hacker News

Don't use booleans (2019)

luu.io

51–60 of 152 posts

Re: Don't use booleans (2019)

#51
post #14

Earlier quoted context omitted.

Which is far more realistic than defining single-use enums all over the place. I don't know why more languages don't have named parameters...

Why is defining an enum "unrealistic"? It's at most 4 lines of very simple code to define an enum that replaces a boolean.

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

Re: Don't use booleans (2019)

#53
post #47

Earlier quoted context omitted.

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.

Point taken. But you can check the declaration of RaiseInvoice and see if the names match. If you had RaiseInvoice(false, true) then you really wouldn't know.

Re: Don't use booleans (2019)

#55

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.

How is this done for js?

Re: Don't use booleans (2019)

#57
post #33

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

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

TypeScript is the answer.

Re: Don't use booleans (2019)

#58
post #33

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

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

Is there anything wrong with taking a single parameter?

Re: Don't use booleans (2019)

#59

Earlier quoted context omitted.

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

How is this done for js?

As far as I know it is not a native feature, but inline hints for parameter names can be added with a VSCode extension called "Inline Parameters for VSCode": https://marketplace.visualstudio.com/items?itemName=liamhamm...

The only languages it supports are JavaScript, TypeScript, PHP, and Lua. I can confirm that it works for JavaScript and TypeScript, I haven't tried the other two.

A similar extension named "Inline Parameters Extended for VSCode" supports a different set of languages: Golang, Java, Lua, PHP, and Python. It seems to be a fork of the aforementioned.

Re: Don't use booleans (2019)

#60
post #38
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.

[deleted]
Post reply on HN