4-5 parameters is already a lot. I usually start thinking at 3. Following clean code. IveI worked on a code base with many parameters added over time… Horrid.

Thanks. Indeed, we could use strong types here. The reason why I didn’t show this in the article was to focus on one aspect of the design at a time. But maybe this doesn’t make the purpose clearer!
Thanks for noticing the typo, it is now fixed.

+1.

It makes extensibility and maintenance much easier. And allows passing around the pack of parameters. It’s a strategy I often use when the function is actually an asynchronous operation, it allows to easily queue parameter pack and treat it later. Which is also often 2-3 layers of code below, so prevents having to modify each layer when a new parameter is added.

And there’s another important aspect that’s missing here, it’s that a structure enforces explicit parameters at the call sites. E.g.:

OptionParameters params;
params.price = 10.0;
params.yearsToMaturity = 7.0;
…
computeOption(params);

Is much clearer than function taking plain values such as computeOptions(10.0, …, 7.0,…).

I don’t feel that makes it less obvious about what to pass to the function, as you simply have to lookout the definition of the structure.

And I’m not convinced “being obvious as to what to pass for them” is the #1 objective for function parameters, I feel like “being obvious as to what IS PASSED TO them” at call sites is even more important. The code we write will be read much more often than we write it, and by other programmers. I don’t think we should make it easier to write the function if that makes it harder to read at call site.

The Boost Parameter library provides that.
https://www.boost.org/doc/libs/1_68_0/libs/parameter/doc/html/index.html

I never tried it though, so can’t tell about its limitations/drawbacks, and it’s an external library, so may not fit all projects.

Are you perhaps contradicting yourself…
In your “computeOption” function prototype you are not following your recommendation in Part2: “Use strong types to make calling your interfaces a no-brainer”
Double for price, yearsToMaturity and strike leaves room for improvement 🙂
I am guessing this was just plain oversight…

PS: Spelling mistake in heading “repecting” should read “respecting”

I’m always fan of packing long list of parameters into a separate structure. You think that 4…5 params is still ok, but then you have to add another one… and replace the call place many times.
With separate structures it’s easier – you just add another field in the separate type, so it’s more scalable and readable.