from Hacker News

N-Params vs. Single Param

by carlos-menezes on 4/17/25, 6:23 PM with 43 comments

by disillusionist on 4/17/25, 6:41 PM
I started using this pattern years ago and haven't looked back. React components are defined using a single properties param and it feels natural to extend the practice to other methods and helper functions that I write.
One nice unexpected side effect is that I end up with more consistency in variable naming when using a param object in order to benefit from object definition shortcuts.
ie I will usually write something like
```
  const firstName = getFirstName(); doTheThing({ firstName });
```
rather than
```
  const fName = getFirstName(); doTheThing({ firstName: fName });
```
by hwpythonner on 4/17/25, 7:09 PM
Not an expert in JS, but maybe this makes sense in JS where everything is passed as objects anyway and having a single param is often more readable there.
But in native languages like C/C++/etc, this pattern usually hurts performance. Separate arguments go into registers (faster but depends on number of arguments), while structs often involve indirection, and sometimes alignment/padding issues. Also, passing a const struct doesn’t guarantee the fields inside are truly const.
That said, it's context dependent. If you're passing stuff through multiple layers or want a more stable function signature, using a struct can be cleaner. Just not something I’d generalize to any language or any use case.
by sixo on 4/17/25, 8:12 PM
A little while ago I sketched some ideas for a programming language [1], one of which was that I would like a language who did not distinguish between these two cases. Obviously you can always write a function with a single N-param argument, but it's rather verbose, but would be nice to also be able to write the param list normally and then refer directly to its parameter type elsewhere. Although this would require that the "set of possible parameter lists" were the same as "the set of possible object type", which isn't the case in any language I know of.
[1] https://samkrit.ch/2025/03/09/programming-1.html#anonymous-t...
by 9d on 4/17/25, 7:03 PM
> No guessing. No worrying about the order. Your code is self-documenting. Plus, TypeScript gives you full autocompletion and type safety.
1. Most of the time, arguments are not the same type, so if you're using TypeScript, you're already getting errors at this point. In your example, only first/last names might get mixed up. And if you still get those wrong while writing that code, you're just phoning it in atp and maybe should take a day off.
2. The same TypeScript that checks your types, also lets you see the signature when hovering over the function.
In real world coding, this isn't an issue, and you'll probably give up keeping this "rule" after a year or two. But good that you're at least thinking about these kinds of things.
by mx-bojangles on 4/17/25, 9:51 PM
I agree that the example is easier to read with the single object param. It might be even easier to read using a fluent interface or a builder pattern. You should choose the best tool for the job.
As a counter-example, I prefer
```
    setEnabled(item, true);
```
to
```
    setEnabled({item: item, isEnabled: true});
```
by tantalor on 4/17/25, 7:11 PM
"Avoid the Long Parameter List"
https://testing.googleblog.com/2024/05/avoid-long-parameter-...

by Joker_vD on 4/18/25, 12:59 PM

Here is a case were object parameters aren't the better choice:

    type TBinarySearchParams<T> = {
        needle: T;
        haystack: [T];
    };

    const binarySearch = <T,>(args: TBinarySearchParams<T>) => { ... }

    binarySearch({needle: 42, haystack: [1,2,3]});

Or at least, I would argue they are not better, but if you still insist:

    type TIsEvenParams = {
        num: number;
    };

    const isEven = (args: TIsEvenParams) => { ... }

    isEven({num: 7});

Surely that is strictly worse?

by jiehong on 4/18/25, 2:00 PM
It’s known as the parameter object pattern[0].
A draw back would be is you want to overload such a method with fewer parameters, it then becomes weird.
[0]: https://wiki.ralfbarkow.ch/view/parameter-object
by simianwords on 4/18/25, 6:29 AM
The other advantage to this pattern is that you can create a generic interface out of this.
With the N-params pattern it is not possible to create an interface on this method because the types of each param may be different across different implementation.
by krystofee on 4/17/25, 8:50 PM
This is just because TS doesnt have keyword or keyword-only arguments as Python for example has.
by joeyagreco on 4/17/25, 7:55 PM
In my opinion, this is the _only_ way to handle n-param functions in production code.