prefer enumerations over booleans

[sap]

prefer enumerations over booleans

[HrFlorianHoffmann]

The section Split method instead of Boolean parameter partially covers this. A little unsure whether linking there will do, or whether we should add a new small sub-section on the choice of data type.

[JLindenberg]

I´d definitely prefer banning booleans in the first place - as a most likely inadequate data type. If then you end up with an enumeration Do.This or Do.That, then you know how to proceed..

[HrFlorianHoffmann]

Added a section Use Booleans wisely that I think closes this issue.

[JLindenberg]

good start, but...

• the link to "Split methods..." is broken (mind the s)
• references 2 & 3 would better fit to "Split methods.." rather than "Use Booleans wisely"
• I am missing the point that readability of booleans is often worse than enumerations even if the domain is binary

[HrFlorianHoffmann]

There are several reasons why I didn't comment on the readability so far.

For once, this affects other languages far more than ABAP, because ABAP usually requires you to repeat the parameter names:

 // Java
updateDocument(true, true, false);

while

" ABAP
update_document( synchronous = abap_true
                 with_commit = abap_true
                 write_logs  = abap_false ).

ABAP becomes ambiguous only when you're down to one parameter and you can ommit the parameter name:

update( abap_true ).

Although this issue frequently occurs with Booleans, it's not caused by them. The issue is in fact caused by the unavailability of the parameter names in the method call, and can happen with all data types. In most cases, enumerations are not even an option:

// Java
someString.substring(0, 3);  // what's 3? length? end index?
sendEmail("", "", "", "");  // title, body, recipient, sender - or the other way round?
assertEquals(a, b);  // which one is the expected value? a or b?

In return, it's not necessary to use a different data type to provide a meaningful enumeration:

" ABAP
CONSTANTS:
  BEGIN OF save_mode,
    with_commit TYPE abap_bool VALUE abap_true,
    without_commit TYPE abap_bool VALUE abap_false,
  END OF save_mode.

update( save_mode-with_commit ).

Over the years, most IDEs added the feature to show parameter names inline without them actually being present in the code. This greatly reduces this issue's impact. As far as I know, the ABAP Development Tools do not (yet) support this feature.

In summary, yes, I agree that it's a good idea to challenge whether a Boolean is the right choice, but this ambiguous-call argument is a rather weak one.

[pokrakam]

Over the years, most IDEs added the feature to show parameter names inline without them actually being present in the code. This greatly reduces this issue's impact. As far as I know, the ABAP Development Tools do not (yet) support this feature.

If I understood correctly, you can do this with <alt>-F2 from anywhere inside a method.

[HrFlorianHoffmann]

That is Eclipse's "Element Info", a quick preview of the method signature in a separate window.

What I mean are "Parameter Hints", as found for example in IntelliJ:

[pokrakam]

Ah, nice!
But I guess since parameter names are required if more than one, then it is less of a priority for ABAP.

[JLindenberg]

agreed - ABAP is better by naming arguments.

sendEmail("", "", "", "");  // title, body, recipient, sender - or the other way round?

actually signatures like these could use more specific types rather then generic types. E.g. recipient and sender could be a class that also provides validation in addition to having a string representation. Is your body html, rtf, or text? Lazy coders..

// Java
someString.substring(0, 3);  // what's 3? length? end index?
assertEquals(a, b);  // which one is the expected value? a or b?

no idea.

[HrFlorianHoffmann]

After the fixes in #25, is there still something we should change?