ABAP Keyword Documentation → ABAP Programming Guidelines → Structure and Style → Alternative Spellings
Other versions: 7.31 | 7.40 | 7.54
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.
Only use chained statements where appropriate
Use chained statements mainly for declarations. They should always be used for related declarations of type
TYPES BEGIN OF ... TYPES END OF ....
The main motivation for using chained statements is to increase the readability of programs. Using chained statements correctly in declarations 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 one statement at most per program line.
For complex declarations, you can use chained statements to improve the readability. (However, if local declarations are too complex, this suggests an insufficient separation of tasks, and should not occur.) In particular, several chained statements can be used to group related declarations:
airplane TYPE REF TO cl_airplane,
airplane_attributes TYPE cl_airplane=>airplane_attributes.
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 statements INCLUDE
INCLUDE STRUCTURE, this 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
no longer recommend using the
For operational statements, however, chained statements are not recommended because they do not usually result in better readability. Example:
CALL METHOD meth EXPORTING para = : '1', '2', '3'.
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 notation can manage without a chained statement anyway:
meth( '1' ).
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
TRY control structure, in which the
CATCH statements are implemented using a chained statement:
CATCH: cx_1, cx_2, cx_3.
A reader and probably even a developer would assume that this is a
CATCH block that handles three exceptions. In fact, the complete syntax is as follows:
cx_2 exceptions are indeed caught,
but the corresponding
CATCH blocks are empty. Only the third exception
cx_3 has a
CATCH block that is not empty. The syntax that the developer presumably intended is as follows:
CATCH cx_1 cx_2 cx_3.
WHEN blocks within a
CASE control structure, the following applies:
WHEN: a, b, c.
is not equivalent to the more probable
WHEN a OR b OR c.
The extended program
check warns of empty statement blocks after
In this way, the extended program check can be used to uncover where chained statements have been misused within
CASE control structures.
Another example in which the use of chained statements can cause problems are Open SQL statements. Here are two examples:
- The following chained statement consists of two
SELECTstatements that both supply a work area with values, and of which only the second one has a
INTO: carrid_wa, connid_wa
WHERE carrid = '...'.
INTO clause was undoubtedly meant here:
INTO (carrid_wa, connid_wa).
- In the following example, the seemingly single statement does not update the discount and the telephone number of the customer with the customer ID 00017777. Instead, these are in fact two statements, of which the first changes the discount for all customers and the second changes the telephone number of the customer with the customer ID 00017777.
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.