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
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 ... .
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 one statement at most per program line
.
Declarations
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:
DATA:
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:
TYPES:
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 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 INCLUDE statement.
Operational Statements
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:
CALL METHOD:
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' ).
Unexpected Behavior
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:
TRY.
...
CATCH: cx_1, cx_2, cx_3.
"exception handling
...
ENDTRY.
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:
TRY.
...
CATCH cx_1.
CATCH cx_2.
CATCH cx_3.
"exception handling
...
ENDTRY.
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:
TRY.
...
CATCH cx_1 cx_2 cx_3.
"exception handling
...
ENDTRY.
For the 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 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 chained statement consists of two SELECT statements
that both supply a work area with values, and of which only the second
one has a WHERE condition.
SELECT SINGLE carrid connid
FROM spfli
INTO: carrid_wa, connid_wa
WHERE carrid = '...'.
The following 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.
UPDATE scustom SET: discount = '003',
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.
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved