61–70 of 119 posts
Named parameters misses the point. Functions should do one thing and only one thing. This is why we have cos, sin, and tan and not a universal function for trigonometry: trig(mode='cos', ...). Such functions often become cumbersome to use since they are essentially multiple functions baked into one.
function pizza(boolean pepperoni, boolean bacon, boolean mushroom, boolean artichoke) now becomes 16 distinct functions.
IntelliJ solves this nicely by showing the parameter name at call sites, effectively making it look like the language has named parameters.
calc_formula(1,2,true)
would show as
calc_formula(a: 1, b: 2, is_gain: true)
but
calc_formula(1,2,some_var)
shows as
calc_formula(a: 1, b: 2, some_var)
Although on the flip side, it creates an incentive for the developer to choose sensible names for variables, functions etc.
Earlier quoted context omitted.
Fwiw, Ada does this too.
Does this feature have a general name? Swift users seem to call it "dot syntax", which is not a good name. I want to google "C++ should have " and find a proposal from 2013 that never moved forward, but "C++ should have dot syntax" is just silly.
https://docs.swift.org/swift-book/ReferenceManual/Expression...
In Delphi I try to use sets over boolean parameters. Then I can easily add new possible set members instead of introducing more parameters. type FuncParam = (fpDoThis, fpDoThat); type FuncParams = set of FuncParam; function MyFunc(arg1, arg2: integer; params: FuncParams): integer; begin result := 0; if (fpDoThis in params) then result := DoThis(arg1); ... end; // supply directly MyFunc(123, 42, [doThis, doThat]); //…
IntelliJ solves this nicely by showing the parameter name at call sites, effectively making it look like the language has named parameters.
The solution provided in the article is the way to go.
IntelliJ solves this nicely by showing the parameter name at call sites, effectively making it look like the language has named parameters.
Fully agree. No need to change the source code to fix what isn't broken.
Choose:
AddElement(object, true, false);
AddElement(object, true, true);
AddElement(object, false, false);
AddElement(object, false, true);
AddElement(object, visible::on, deletable::off);
AddElement(object, visible::on, deletable::on);
AddElement(object, visible::off, deletable::off);
AddElement(object, visible::off, deletable::on);
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));
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 constructor have required arguments (or throw a runtime error upon finalizing the builder).
Earlier quoted context omitted.
Fully agree. No need to change the source code to fix what isn't broken.
Code is for humans, not for computers. Choose: AddElement(object, true, false); AddElement(object, true, true); AddElement(object, false, false); AddElement(object, false, true); or AddElement(object, visible::on, deletable::off); AddElement(object, visible::on, deletable::on); AddElement(object, visible::off, deletable::off); AddElement(object, visible::off, deletable::on); The latter is more readable, you can spot…
In python, I love keyword-only arguments for this. Then the caller has to write: v = calc_formula(ia, ib, is_gain=true) You also have the option of defining a default value for the argument so the old call-sites don't even need modification.
def calc_formula(first, second, *, is_gain=False):
…Earlier quoted context omitted.
My rule of thumb these days in JS/TS is all functions with more than 2 parameters should be refactored to a single object parameter using destructuring. I don't start with a single object because most times YAGNI applies.
> My rule of thumb these days in JS/TS is all functions with more than 2 parameters should be refactored to a single object parameter using destructuring. Does this create garbage for the garbage collector (which might be an issue for inner loops)?
So yes, if performance is critical you should probably profile and consider avoiding this pattern, but for most cases the performance impact is very minor.