SAP MODERN ABAP - Guide
Get Example source ABAP code based on a different SAP table
GUIDELINE 3.5
Modern ABAP
ABAP_BACKGROUND
ABAP is a living programming language that is continually being developed. Since its introduction some 30 years ago, new ABAP programs have been developed continually, with work to advance the ABAP language ongoing at the same time. Developments to the ABAP language are either extensions of the existing language attributes to implement new functionality, or the replacement of existing functionality with more advanced concepts. The replacement of existing language elements with new ones usually makes the existing language elements superfluous or obsolete. The most prominent example of a development of the ABAP language is still the implementation of ABAP Objects.
With regard to the ABAP language, SAP has committed itself to a policy of strict downward compatibility. This means that an ABAP program written for release 3.0, for example, can be executed on an
To remedy these problems, you can use the following simple rule.
ABAP_RULE
Do not use obsolete language elements for new developments. We also recommend an incremental changeover to new concepts as they become available.
ABAP_DETAILS
Newer language elements are always the better language elements. Obsolete language elements are only provided for downward compatibility reasons. A statement or statement addition is declared as obsolete only when a more powerful alternative exists or when the language element is identified as being prone to errors (in the sense that it invites insecure and non-robust programming). For this reason, secure and robust programming is not possible if obsolete language elements are used, which makes the use of such obsolete language elements out of the question for new developments.
If ABAP Objects is used, the majority of the obsolete statements and additions are already prohibited syntactically. For this reason among others, we strongly recommend
Bad Example
The following source code shows the solution of a task using obsolete language elements. A procedure is supposed to replace all occurrences of
new TYPE csequence
CHANGING text TYPE csequence.
DATA: pattern TYPE string,
subrc TYPE sy-subrc.
CONCATENATE '*' substring INTO pattern.
SEARCH text FOR pattern.
IF sy-subrc <(><<)>> 0.
CLEAR subrc.
WHILE subrc = 0.
REPLACE substring WITH new INTO text.
subrc = sy-subrc.
ENDWHILE.
ENDIF.
ENDFORM.
In the above source code, aside from the modularization with
Good Example
The following source code executes the same task as above; however, it uses the latest available language elements.
FIND REGEX substring <(> <)><(> <)> `` IN text.
IF sy-subrc <(><<)>> 0.
REPLACE ALL OCCURRENCES OF substring IN text WITH new.
ENDIF.
ENDMETHOD.
The subroutine is replaced with a method. By using
Note
In connection with the above rule, the question on the coexistence of old and new concepts within a program unit arises. There is only one area in which this is clearly syntactically defined, that is, the use of the
However, this does not mean that in enhancements to existing procedures you should continue to use obsolete language elements to keep consistency, just because they already exist. Rather, you should seize the opportunity to switch the entire procedure to the corresponding new language elements. By using module tests to cover the procedures to be changed, you can ensure that there will be no unpleasant surprises during the changeover.