Get rid of those boolean function parameters (2015)

Post by zamadatix » Mon, Sep 20, 2021, 4:10 PM UTC

peoplefromibiza wrote: post #51

treve wrote: post #41

Earlier quoted context omitted.

Religiously splitting functions with boolean arguments doesn't always result in more maintainable code. Instead of trigonometry functions, how would you refactor JS's fetch() with many of its behaviour-altering flags?

> how would you refactor JS's fetch() as @flavius29663 said ( https://news.ycombinator.com/item?id=28593669 ) you can use the builder pattern FetchBuilder() .withUrl(ur) .withMode("cors") .withCache(true) .withHeader('Content-Type', 'application/json') .accept('*/*') .post() .then(response => response.json()) .then(data => console.log(data));

    // The original "misses the point"
    trig(mode="cos", type="hyperbolic")
    
    // The style fetch() uses today
    trig({mode: "cos", type: "hyperbolic"})
    
    // The builder refactor
    trigBuilder().withMode("Cos").withType("hyperbolic").calculate()

Post by kevincox » Mon, Sep 20, 2021, 4:17 PM UTC

peoplefromibiza wrote: post #72

kevincox wrote: post #67

Earlier quoted context omitted.

I see the builder pattern as a way to manage lack of keyword arguments. I see very little difference between your example and the actual fetch API that takes an object as JS's version of keyword arguments. Languages with good support for named/keyword arguments have more features such as required arguments and preventing duplicate arguments. With builder patterns your only real option is to make the builder construct…

> . I see very little difference between your example and the actual fetch API that takes an object as JS's version true the only difference is in the tooling code completion for methods names works much better than autocompletion for objects' fields. And you can't mistype a method name, it would not run and give you back a - hopefully - meaningful error, while the same is not true for objects' fields.

Post by stnmtn » Mon, Sep 20, 2021, 4:56 PM UTC

kall wrote: post #47

cphoover wrote: post #34

Earlier quoted context omitted.

In JS we can use JSON/object literal syntax and object destructuring to serve a similar purpose: myFunc({ aBoolFlag : true, anotherBoolFlag : false, aString : "Hello World" }); const myFunc = ({ aBoolFlag, anotherBoolFlag, aString }) => { /* do something with them... */ };

I started doing this because of React but at this point ({}) is my default way of starting a function. The only thing I dislike is that it's not super ergonomic for explicit typescript declarations (but great when using typescript to check .js files).

  interface IFunctionParameters {
    userId: string;
    name: string;
    age: number;
  }

  const example = ({userId, name, age}: IFunctionParameters) => {...}

Post by flavius29663 » Mon, Sep 20, 2021, 5:19 PM UTC

stnmtn wrote: post #76

flavius29663 wrote: post #49

Earlier quoted context omitted.

pizza is very suitable for the builder pattern: CreatePizza() .WithBacon() .With(artichoke) .Build(); or any combination of the above: CreatePizza() .WithMussroom() .Build() Even better, you can add new ingredients without changing any of the existing signatures: CreatePizza() .WithProsciuto() .WithTomatoSauce() .Build()

What is the difference of this and doing an object paramater, similar to JS? createPizza({bacon: true, artichoke: true}); This has the same benefit you describe of being able to add parameters without altering any old call sites createPizza({prosiuto: true, tomatoSauce: true});

Post by debacle » Mon, Sep 20, 2021, 5:26 PM UTC

nirvdrum wrote: post #35

debacle wrote: post #32

If someone submitted a PR where all of their boolean parameters were actually enums I would reject it, open a PR of my own from the same branch, and reject that one too. These clever micro-optimizations are a pathology of bored, well-meaning developers.

Could you please elaborate? To me, it looks like the article posits using boolean flags instead of enums is a code legibility issue, not a performance matter. There may still be good reason to reject a large PR such as the one you described. But, I don't get where the micro-optimization appears.