81–90 of 119 posts
Earlier quoted context omitted.
Fully agree. No need to change the source code to fix what isn't broken.
While I think parameter names at all call sites is the right solution, I don't think it's good enough to have this in the IDE alone. I still have to review code online that says `add(a, true)`, even if IntelliJ showed me `add(a, ignore_negatives:true)`.
With keyword arguments, this problem goes away, and not just for boolean arguments but for arguments generally.
Earlier quoted context omitted.
While I think parameter names at all call sites is the right solution, I don't think it's good enough to have this in the IDE alone. I still have to review code online that says `add(a, true)`, even if IntelliJ showed me `add(a, ignore_negatives:true)`.
The point is that this is a presentation issue. There is nothing wrong with the model. It would not be impossible for the reviewing software to analyze source code and display named parameters.
I think the point was that it shouldn't be.
> There is nothing wrong with the model
Seems to me there is.
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]); //…
Citation, as they say, needed. :-)
Earlier quoted context omitted.
not necessarly. First of all, this function pizza(boolean pepperoni, boolean bacon, boolean mushroom, boolean artichoke) breaks down when you want to add ham, potatoes and sausages to the pizza. Secondly, you can optimize for the common case: fn pizza() # -> default pizza e.g. margherita fn pizza(list_of_ingredients) # -> your custom pizza if you we are talking of simple functions and not more complex patterns, such…
What kind of monster puts potatoes on a pizza?
Earlier quoted context omitted.
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});
In my example the could matter, or not. I see this all the times. In your example, can you make the order matter? In my example, after each selection, you can limit or expand the further options.
if Shrimp in Fillings then begin
Add(Shrimp);
Add(ShrimpOil); // So yummy together
Fillings.Remove(Jalapenos); // Don't go together
end;
if Jalapenos in Fillings then begin
Add(Jalapenos);
end;
Earlier quoted context omitted.
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.
It's a readability optimization, not a performance optimization.
Earlier quoted context omitted.
In my example the could matter, or not. I see this all the times. In your example, can you make the order matter? In my example, after each selection, you can limit or expand the further options.
Nothing to stop you from doing the same within the code of the multi-parameterized single function, is there? if Shrimp in Fillings then begin Add(Shrimp); Add(ShrimpOil); // So yummy together Fillings.Remove(Jalapenos); // Don't go together end; if Jalapenos in Fillings then begin Add(Jalapenos); end; etc. No?
In your case you would end up calling your function like this: DoToppings(true, false, true, true);
Whereas in my case you would call the builder directly with (only) the params you want different than the defaults.
You could use named arguments, but that doesn't solve the problem completely. You will still have a large method signature, hard to use, harder to refactor, harder to test, error prone.
It also causes a lot of redundant code: the called usually only cares about one or 2 arguments, it's rare that you *need* to pass more. The rest of the args are filled in by defaults in the implementation. There could be elegant ways to handle the defaults, like overloading methods or just passing in defaults in the method signature. Default value are pretty bad IMO, for all the reasons above. Btw, if you *need* to pass that many arguments to a function, that is another code smell worth it's own discussion.
Multiple overloaded methods could have about the same amount of code int he implementation like the builder pattern, but they have a huge drawback: the caller cannot mix and match which arguments they want to pass in. If you have 4 arguments, there would be quite a high combination of parameters (18 possibilities? - 18 functions); Using the builder pattern you have to implement 4 methods only, and you're covering all the possible combinations the client might want. You can also limit some combinations in elegant ways right in the IDE while the developer is writing the code.
Think of FluentAssertions https://fluentassertions.com/introduction They have literally hundreds of possible assertions that are represented by object instances. You can combine them in an almost infinite number of possibilities.
Sure, there is no black and white, and depends on the language, the builder pattern is a good tool to have in the toolbox.
Earlier quoted context omitted.
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…
With a good IDE, the first one can be configured to look like the 2nd one. But the 2nd one will always be more verbose, no matter if you need it or not. So I'd choose the first one.
Earlier quoted context omitted.
The point is that this is a presentation issue. There is nothing wrong with the model. It would not be impossible for the reviewing software to analyze source code and display named parameters.
OTOH, programming for the human and not for the computer, included caring about presentation. I could say there's nothing right with the model either - a non-issue, personal preference. ... An older presentation issue is the tabs versus spaces flamewar. At least that one has burnt out. Maybe because of the rise of IDE's?
My guess would be not IDEs but autoformatting tools, especially when communties like Go all follow one style.