SAP NetWeaver AS ABAP Release 751, ©Copyright 2017 SAP AG. All rights reserved.
ABAP - Keyword Documentation → ABAP Programming Guidelines → Structure and Style → Alternative Spellings →Chained Statements
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 handled 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 keyword.
Rule
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 ....
Details
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, only one statement at most should be specified per program line. Never span expressions or functional calls across multiple parts of chained statements.
Declarations
In complex declarations, chained statements can be used to improve readability. (However, if local declarations are too complex, this suggests an insufficient separation of tasks, and should not occur.) In particular, multiple chained statements can be used to group related declarations:
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:
For structures that copy components of another structure using the statements INCLUDE TYPE or 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 statement INCLUDE.
Operational Statements
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 chained statement would be easier to read:
However, in this case the best notation can manage without a chained statement anyway:
Unexpected Behavior
If chained statements are not understood correctly, this can easily produce statements with correct syntax but 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:
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:
The cx_1 and 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:
For the WHEN blocks within a CASE control structure, the following applies:
is not equivalent to the more probable
The extended program check warns of empty statement blocks after CATCH and WHEN. In this way, the extended program check can be used to uncover where chained statements have been misused within TRY and 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 INTO clause was undoubtedly meant here:
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.
Expressions and Function Calls
Unfortunately, ABAP statements can be spanned across the colon in chained statements, even within expressions or function calls. The following example with correct syntax shows what can happen here, even in the simplest of cases. This example cannot be understood and nor does it produce the expected result.