We encourage you to get rid of all encoding prefixes.
METHOD add_two_numbers. result = a + b. ENDMETHOD.
instead of the needlessly longer
METHOD add_two_numbers. rv_result = iv_a + iv_b. ENDMETHOD.
Read more in Chapter 2: Meaningful Names: Avoid Encodings of Robert C. Martin's Clean Code. The examples in this style guide are written without prefixes to demonstrate the value.
This section contradicts the sections Names of Repository Objects and Program-Internal Names of the ABAP Programming Guidelines which recommend to use prefixes. We think that avoiding prefixes is the more modern and readable variant and that the guideline should be adjusted.
SAP has a bad, pervasive legacy practice of adding prefixes to each and everything, to encode things like
- kind, such as "cl_" for classes,
- direction, such as "is_" for an input parameter,
- scope, such as "mo_" for a class member,
- type, such as "lt_" for a table-like variable, and
- mutability, such as "sc_" for a constant.
This kind of prefixing is a relic from the early days of programming, when code was printed out and read on paper, and you didn't want to flip around just to find some variable's type. Modern development environments give easy access to data types, signatures, and object navigation, such that it is no longer needed to get readable code.
Before you disagree, consider these:
ABAP's 30 character limitation makes it hard enough to squeeze meaningful names into the available space without wasting another 3-4 characters for needless encodings.
The disputes that arise over prefixes are not worth the effort: whether your constant starts with
cv_does not really influence readability.
Squeezing the at least five dimensions of variables (kind, direction, scope, type, mutability), into usually no more than two character prefixes leads to pointless conflicts.
Different team styles create confusion: is "lr_" an object reference or a range table? You'll stumble over this in code that connects different things, for example your determinations within BOPF.
Prefixes can be misleading. For example, despite their names, the "importing data"
id_business_partnerhas nothing to do with the business partner's ID, and the "large object string"
lost_file_contentis not lost at all.
Changes create needless work: turning a table from
SORTEDshouldn't require you to rename all variables from "lt_" to "lts_".
Prefixing doesn't make it easier to tell global from local things. If you fill a
lt_sum, both are still only sums and it's not clear what distinguishes the two. The better idea is to fill a
partial_sum, or an
intermediate_result. The name confusion described in section Program-Internal Names in the ABAP Programming Guidelines should thus be solved otherwise.
Prefixing doesn't make it easier to recognize data types. For example, most Hungarian ABAP encodings distinguish variables from structures and tables, but don't reflect the way more important differentiation between floating point and packed numbers.
If you follow Clean Code, your methods will become so short (3-5 statements) that prefixing is no longer necessary to tell importing from exporting parameters and local from global variables.
The ABAP foundation doesn't prefix anymore, for example you won't find importing/exporting prefixes on the method parameters in
Other languages like Java use absolutely no prefixes, and still Java code is perfectly readable.
There is only one prefix that ABAP forces you to use: your application's namespace, to avoid conflicts with objects from other teams in the global dictionary, where every thing needs a unique name.
If this rule is too hard for you, consider a compromise: avoid encodings in local contexts (within a method body, method parameters, local classes, etc.), and apply them only to global objects that are stored in the same global Dictionary namespace.
We agree that following this suggestion will work out only if the code is already clean in some other aspects, especially short methods and good method and variable names. While prefixes needlessly complicate a clean method with two statements, they may be your only remaining lifeline in a thousand-line legacy function with cryptic variable names.