SAP CHAINED STATEMENTS - Guide
Get Example source ABAP code based on a different SAP table
GUIDELINE 4.17
Chained Statements
ABAP_BACKGROUND
Successive ABAP statements that have the same starting part can be expressed in a chained statement. A chained statement consists of the identical starting part that is specified once and that is concluded by a colon (:). Behind this colon, the remaining parts are separated by commas (,). Only the last part is concluded with a period (.). During the syntax check and the compilation, a chained statement is treated like the respective sequence of individual ABAP statements, where the shared starting part is put in front of each remaining part. The identical starting parts are not restricted to the key word.
ABAP_RULE
Use chained statements mainly for declarations. They should always be used for related declarations of type
ABAP_DETAILS
The main motivation for using chained statements is to increase the readability of programs. Using chained statements correctly in d eclarations achieves this goal. In other statements, chained statements can actually decrease the readability or, in the worst case, result in incorrect program behavior. When using chained statements, you should execute
For complex declarations, you can use chained statements to improve the readability. (However, if local declarations are too complex, this suggests an
airplane TYPE REF TO cl_airplane,
airplane_attributes TYPE cl_airplane=>airplane_attributes.
DATA:
airport TYPE REF TO cl_airport,
airport_attributes TYPE cl_airport=>airport_attributes.
...
The grouping of declarative statements that semantically represent a composite statement is even more important. For example, the declaration of structured types and data objects in ABAP is done using individual statements, whose close relationship should be expressed by a chained statement:
BEGIN OF file,
name TYPE string,
owner TYPE sy-uname,
creation_date TYPE timestamp,
END OF file.
For structures that copy components of another structure using the ABAP Code Snippet procedure cannot be used consistently because the beginning of the statement is different and therefore the chained statement must be interrupted. In any case, we
For operational statements, however, chained statements are not recommended because they do not usually result in better readability. Example:
Here, the exploitation of the fact that the same starting parts in front of the colon are not limited to the keyword was a little overdone. The following chain statement would be easier to read:
meth EXPORTING para = '1',
meth EXPORTING para = '2',
meth EXPORTING para = '3'.
However, in this case the best
meth( '2' ).
meth( '3' ).
If chained statements are not understood correctly, this can easily result in the creation of syntactically correct statements with unexpected behavior. Prominent examples are introductory statements within control structures. Here, the use of chained statements does not usually lead to the intended result.
Let us look at the following
...
CATCH: cx_1, cx_2, cx_3.
'exception handling
...
ENDTRY.
A reader and probably even a developer would assume that this is a
...
CATCH cx_1.
CATCH cx_2.
CATCH cx_3.
'exception handling
...
ENDTRY.
The
...
CATCH cx_1 cx_2 cx_3.
'exception handling
...
ENDTRY.
For the
is not equivalent to the more probable
The
Another example in which the use of chained statements can cause problems are
FROM spfli
INTO: carrid_wa, connid_wa
WHERE carrid = '...'.
The following
telephone = '0621/444444'
WHERE id = '00017777'.
Even if the previous examples of the chained statements would show the semantic that is expected by the developer, such use is not recommended in any case because each reader would probably expect a different program behavior, and the readability and maintainability of the source code would be impaired considerably.