Avoid encodings, esp. Hungarian notation and prefixes

[sap]

Avoid encodings, esp. Hungarian notation and prefixes

[HrFlorianHoffmann]

An interesting case. Some prefix or suffix would definitely fix this.

Consider these prior thoughts:

An alternative to Hungarian prefixes might be adding a more elaborate name. For example, we could call the types transport_change_row and transport_changes_table. Or in reverse call the attribute collected_transport_changes.

This is similar to the classical interface-vs-class-name conflict, that goes like this: "I have a data_provider interface and a single data_provider class that implements it. Which of the two do I rename, and how, to avoid a name conflict?"

Extracting the types to another development object, such as a local interface local_types would fix the syntax error. Similarly, extracting the types to the data dictionary would probably also fix it - unless the global table type's name would again be transport_changes.

If this conflict appears often, it may justify using extensive prefixing. If it is seldom, we need to weight whether it is acceptable to prefix 2,048 types and members only to avoid 16 name clashes, and probably 16 more unforeseen ones in the future.

Java-vs-ABAP comarators have repeatedly pointed out that Java distinguishes the two with typesetting the first character, as in DataProvider (the class) vs. dataProvider (the private attribute). However, porting this to ABAP only justifies something like a very general t_ prefix for any type-like declaration, to be used for all classes, interfaces, data elements, structures, table types etc. It does not justify some elaborate schema such as mtt in your example, which also encodes the context (m for "member") and type (first t for table).

Also consider how prefixing again introduces misunderstandings. In many SAP teams, mt_ would be a "tabular class attribute", and tt_ a local table type definition, making mtt_ a confusing mixture of non-mixable concepts.

[thomham]

I just made a pull-request to make some examples how to avoid name clashes like you describe it. Maybe we can extend it to also cover the type vs. variable conflict.

For your example above you basically gave the solution already.

• The type describes a change_request.
• The variable makes it more specific as a transport_change_request.

So it is a matter of coming from the more generic to the more specific. And as always, naming is not easy. ;-)

CLASS zcl_tms_transport DEFINITION
  PUBLIC
  CREATE PUBLIC .

  PUBLIC SECTION.
    " ...
  PRIVATE SECTION.
    TYPES:
      BEGIN OF change_request,
        change_request_key         TYPE key,
        transport_request          TYPE trkorr,
        date_quality_assurance     TYPE lxeexphead_impdate,
    END OF change_request.
    TYPES:
      change_requests TYPE SORTED TABLE OF
        change_request WITH UNIQUE KEY change_request_key.

    DATA transport_change_requests TYPE change_requests . "syntax error gone
    " ...
ENDCLASS.

[bjoern-jueliger-sap]

Since there was no further discussion here after #101, this issue can be considered closed.