3 ms·

What named parameters fixes is making constant parameters readable. You can API design around this (see for example https://wiki.qt.io/API_Design_Principles#The

What named parameters fixes is making constant parameters readable. You can API design around this (see for example https://wiki.qt.io/API_Design_Principles#The_Boolean_Parameter_Trap https://wiki.qt.io/API_Design_Principles#The_Boolean_Paramet... ). You can also always use local constants. But those are non-trivial or cumbersome in their own way, and often people don't for their own internal functions. Named parameters neatly side-steps the issue entirely, by rolling the "local constant" right into the function call itself. Like consider these two python snippets: ['Ford', 'BMW', 'Volvo'].sort(true) vs. ['Ford', 'BMW', 'Volvo'].sort(reverse=true) The latter is much more readable than the former, and there wasn't any "too many parameters" issue. It's a way to help create self-documenting code that's also compiler enforced. And it absolutely frees the reader up from needing to go lookup what the boolean parameter on "sort" means.

koyote 6y ago
Although I agree in general, I think that most of the time this should be solved on the API level (like your link suggests). This is because although you 'can' name your parameters, there is nothing forcing you to. This means that many people forget or are too lazy, so you still end up with a large part of your code not being as readable as it could be. For the above you'd have an 'rsort' or 'reversesort' function instead (or if your language supports it, some fluent kind of sort().reverse()). If you have a lot of options, some of them boolean, you might send in an options struct or have an enum as mentioned in the article.
vore 6y ago
Another pattern especially for ambiguous Boolean parameters I also find helpful is something like (in pseudo-ish code): enum SortDirection { FORWARD, REVERSE } sort(direction : SortDirection = SortDirection.FORWARD) { ... } ['Ford', 'BMW', 'Volvo'].sort() ['Ford', 'BMW', 'Volvo'].sort(SortDirection.REVERSE)
- kllrnohj 6y ago
  Yup, that's the API design tweak that QT recommends as well. But it's a lot more boilerplate, and that sort of boilerplate basically never happens for internal-only methods. Named parameters is basically the middle ground solution for the "quick" hacks that have a tendency to be rather permanent hacks.
tomp 6y ago
This would better be solved with keywords / literal types / singelton types ['Ford', 'BWM', 'Volvo'].sort(`reverse) TypeScript can do that with strings: https://www.typescriptlang.org/docs/handbook/literal-types.html https://www.typescriptlang.org/docs/handbook/literal-types.h...
mwcampbell 6y ago
On the Windows team at Microsoft where I work, we work around the lack of actual named parameters by putting parameter names in C-style comments. To illustrate, given a hypothetical list class with a sort method like Python's, with a boolean "reverse" parameter, we'd call that method like this: list.sort(true /* reverse */); This convention is very handy for certain Win32 functions that take lots ofparameters, such as CreateProcess or CreateWindowEx.
vips7L 6y ago
Java solved this by using comparator objects: var lst = someLst(); lst.sort(Comparator.reverseOrder());

koyote 6y ago

Although I agree in general, I think that most of the time this should be solved on the API level (like your link suggests). This is because although you 'can' name your parameters, there is nothing forcing you to. This means that many people forget or are too lazy, so you still end up with a large part of your code not being as readable as it could be. For the above you'd have an 'rsort' or 'reversesort' function instead (or if your language supports it, some fluent kind of sort().reverse()). If you have a lot of options, some of them boolean, you might send in an options struct or have an enum as mentioned in the article.

vore 6y ago

Another pattern especially for ambiguous Boolean parameters I also find helpful is something like (in pseudo-ish code): enum SortDirection { FORWARD, REVERSE } sort(direction : SortDirection = SortDirection.FORWARD) { ... } ['Ford', 'BMW', 'Volvo'].sort() ['Ford', 'BMW', 'Volvo'].sort(SortDirection.REVERSE)

kllrnohj 6y ago
Yup, that's the API design tweak that QT recommends as well. But it's a lot more boilerplate, and that sort of boilerplate basically never happens for internal-only methods. Named parameters is basically the middle ground solution for the "quick" hacks that have a tendency to be rather permanent hacks.

tomp 6y ago

This would better be solved with keywords / literal types / singelton types ['Ford', 'BWM', 'Volvo'].sort(`reverse) TypeScript can do that with strings: https://www.typescriptlang.org/docs/handbook/literal-types.html https://www.typescriptlang.org/docs/handbook/literal-types.h...

mwcampbell 6y ago

On the Windows team at Microsoft where I work, we work around the lack of actual named parameters by putting parameter names in C-style comments. To illustrate, given a hypothetical list class with a sort method like Python's, with a boolean "reverse" parameter, we'd call that method like this: list.sort(true /* reverse */); This convention is very handy for certain Win32 functions that take lots ofparameters, such as CreateProcess or CreateWindowEx.

vips7L 6y ago

Java solved this by using comparator objects: var lst = someLst(); lst.sort(Comparator.reverseOrder());