SAP
Omit the parameter name in single parameter calls
Omit the parameter name in single parameter calls
DATA(unique_list) = remove_duplicates( list ).instead of the needlessly longer
" anti-pattern DATA(unique_list) = remove_duplicates( list = list ).There are cases, however, where the method name alone is not clear enough and repeating the parameter name may further understandability:
car->drive( speed = 50 ).
Maybe this question is related to optional parameters, which also were recommended to omit. We have cases like: Function module used across many teams, when change of parameters causes dumps on all the places, where it is used. Then there is a possibility to maintain it just by adding OPTIONAL parameters. Now back to this recommendation – if it were opposite (use always name of all the parameters), then no adaptation of method callers is needed. That is why I would say “use the parameter names always, not never”. But I would ask, what do you recommend about maintaining of widely used function module and optional parameters. How to solve situation as above? PS: pity that we have no chance to overload the method. I would say optional parameters are in ABAP to compensate it. Together with this, DEFAULT parameters would also causes the same problems as OPTIONAL ones, since they can be skipped within function call. Are those rules also valid for DEFAULT? Then, we have keyword PREFFERED, which could also help. But I feel the simplest is simply to state the parameter names. It seems to me no deal.
An observation: The argument runs both ways.
Suppose I have a method drive and want to rename its parameter speed to speed_in_mph.
Consumers calling ->drive( 50 ) are fine. Consumers calling ->drive( speed = 50 ) have to adjust to ->drive( speed_in_mph = 50 ). In this case, naming the parameter is worse than omitting the name.
Another observation: Adding parameters that are OPTIONAL or have a DEFAULT is compatible.
Suppose I have a method drive with a parameter speed and want to add a parameter unit.
Adding unit TYPE char3 OPTIONAL or unit TYPE char3 DEFAULT 'MPH' is okay. Neither breaks consumers that call ->drive( 50 ).
One more observation: This touches key questions of stable API design.
APIs, and that includes classes and functions that serve as APIs, should change only in compatible ways.
For a method, this means that the change must not break any existing calls, neither from a technical nor from a logical point of view. Renaming a parameter or adding a mandatory parameter are incompatible changes because it (likely) breaks existing calls. Adding an OPTIONAL or DEFAULT parameter is compatible if omitting the parameter produces the same behavior as before, when the parameter did not exist.
Hello again, I have tested your points and you are right. a) If method has just one parameter and OPTIONAL of DEFAULT is added, the CALL without parameter name remains OK. b) If a method has 1 normal parameter + 1 OPTIONAL parameter, it must be called with the parameter names (if uses both), so again no harm to add a third parameter, also OPTIONAL. c) But there is a case, which can be wrong: If a method has only one parameter, which is OPTIONAL. If such method is called without the parameter name... Then if we add a second OPTIONAL parameter, the method call will be wrong. I see just one advice to put PREFERRED PARAMETER on the first one.
IMHO in the example given either the method name (drive) is not descriptive enough or it violates "the method should do one thing" concept. Either there should be 2 methods, e.g. set_speed( 50 ) and drive( ) or the method should be drive_with_speed or something more than just "drive".
I feel there is no issue here and the problem is that Clean ABAP was not followed in other parts of the program, which lead to it causing such ambiguity.
Side note. "Drive" example is not the best here as we don't really set speed and then drive IRL but in SAP world, similar business object methods frequently end up being "overloaded" with parameters. I fall into this trap myself frequently because especially for experienced ABAPers creating more smaller things goes counter to what we've been taught for years before. But the whole point of Clean ABAP is to get away from such mentality, not to indulge it.
