SAP / styleguides

This repository provides SAP style guides for coding and coding-related topics.
Other
1.68k stars 444 forks source link

Restrictions in identifiers regarding prefixes / type encodings #273

Open fabianlupa opened 2 years ago

fabianlupa commented 2 years ago

In the guide the following section is included:

https://github.com/SAP/styleguides/blob/edd95d5d3428f763e2e11a25c7e7255d2d06d515/clean-abap/sub-sections/AvoidEncodings.md?plain=1#L175-L176

I don't think that's correct / too broad of a statement. Here are two examples I recently ran into where naming restrictions apply that are not a problem when using prefixes:

Class and interface components need unique names regardless of component categories

This is not allowed (syntax error):

CLASS drink DEFINITION.
  PUBLIC SECTION.
    TYPES drink TYPE string.
    DATA drink TYPE drink.
    METHODS drink IMPORTING drink TYPE drink.
ENDCLASS.

Each class or interface component name needs to be unique regardless of their category. This restriction does not apply to local scopes in implementations (it does for local classes and interfaces as well though). See here:

https://help.sap.com/doc/abapdocu_756_index_htm/7.56/en-US/index.htm?file=abenclass_component.htm

All the components in a class are in the same namespace. Within a class, the name of a component must be unique, regardless of its type (data type, attribute, method, event, or alias name).

Exception classes require CX prefix when created using SE80/SE24

image

This is not an issue in ADT (but IDE shaming is bad).


To be clear, I don't think the recommendation of not using type encodings is bad but the text in the reasoning is a bit too "optimistic" and maybe some guidance on how to solve issues would help as well (like in the first example keep drink as the type, rename the data declaration to current_drink and rename the method from drink to commence_with_the_drinking).

https://github.com/SAP/styleguides/blob/edd95d5d3428f763e2e11a25c7e7255d2d06d515/clean-abap/sub-sections/AvoidEncodings.md?plain=1#L113-L114

This is also debatable by the way. Constants in Java by convention use UPPER_SNAKE_CASE which is a kind of type encoding in my opinion (that of course wouldn't work in ABAP) and most exception classes have an Exception suffix in the identifier which is rather comparable to a CX prefix, just takes up way more of the 30 available characters. (Of course technically neither of these two examples are prefixes...)

Edit: Also what about this?

https://github.com/SAP/styleguides/blob/edd95d5d3428f763e2e11a25c7e7255d2d06d515/clean-abap/sub-sections/AvoidEncodings.md?plain=1#L109-L111

There's a CL prefix in the name? Like right there?

jordao76 commented 2 years ago

Java names are still scoped to a package and allow much longer names. ABAP names are global and using simple names wouldn't work. You definitely need some kind of prefix or a namespace prefix (with /) for global names in ABAP. Too bad they take valuable space.

fabianlupa commented 2 years ago

I just noticed another thing: The namespace for classes and interfaces is also shared with the DDIC types addressable from ABAP which wasn't that obvious to me before but of course makes sense as TYPE REF TO can either point to an object reference or a data reference. This never happens with prefixes as you don't tend to use these for DDIC types.

If for example I want to create an enum class to provide constants for the values of a domain, like suggested here, then I can name the data element ZABC_MESSAGE_TYPE, I can name the domain ZABC_MESSAGE_TYPE but I cannot name the enum class ZABC_MESSAGE_TYPE as well. I guess I need to suffix it like ZABC_MESSAGE_TYPE_ENUM ... :)

fabianlupa commented 2 years ago

I'll just keep adding things I run into to the issue :)

If you change an attribute of a class, for example IS_FOLDER, to a method, IS_FOLDER( ), then global classes do not allow you to do that. You need to first change the attribute name to something else or delete it, activate, and then create the method. This of course doesn't happen with prefixes for attributes by accident. I assume this applies to switching between all class / interface component categories.

image