You are on page 1of 3

Extended Program Check

Background
You can call the extended program check for activated programs either from the ABAP
Workbench or by using transaction SLIN. It performs static checks that are too complex for the
normal syntax check. You can perform either individual or multiple subtests, or a standard check
that includes important subtests.
The extended program check outputs errors, warnings and messages. The standard check outputs
errors and warnings that are particularly critical. The classification of individual results (error,
warning or message) depends on whether you perform a standard check or explicitly selected
individual checks. The extended program check also displays the errors and warnings of the
syntax check.
In the initial screen of the extended program check, you can also select a programming
guidelines check. This checks whether certain rules presented in this book (that can be verified
statically) have been adhered to.
The messages from the extended program check, which are inapplicable in some special cases,
can be hidden using pragmas. Before the introduction of pragmas, it was not possible to hide
messages raised by a normal syntax check.
Rule
Use the extended program check
Use the extended program check and take the results seriously. Message are not allowed to
appear when the standard check is performed for a completed program.
Details
The errors, warnings and messages output by the extended program check are just as important
as the syntax errors and syntax warnings from the syntax check. For example, an error reported
by the extended program check can indicate that a program will definitely lead to a runtime error
when it is executed. Warnings and messages usually indicate a questionable use of language
elements, which is likely to cause unexpected program behavior.
In rare cases, when a result reported by the extended program check is not justified, this must be
documented using an appropriate pragma (the relevant pragma is indicated in the message). This
means that the system suppresses the message of the extended program check. Ideally, in less
obvious situations, an additional comment should be used to describe why the message is not
applicable.

Note
The extended program check provides useful help for writing ABAP programs in the correct
way. Using unspecific pseudo comments or pragmas can undo the positive effect of the extended
program check. In particular, you should never use the statement
SET EXTENDED CHECK OFF.
, which suppresses all messages of the extended program check for an entire source code section.
If the ABAP program is submitted to a code review, the results of the extended program check
should be used to evaluate the quality.
Bad Example
If the following source code is checked using the extended program check, a warning appears. It
indicates a particularly questionable query of the content of thereturn value sy-subrc.
ASSIGN field TO <fs>.
IF sy-subrc <> 0.
...
ENDIF.
The program section shows a typical error in a syntactically correct program. The developer
wrongly assumes that the static form of the ASSIGN statement sets the sy-subrc system field,
which is not the case. The developer wrongly believes that he has secured his program. An
incorrect program behavior occurs if sy-subrc has a value that is not zero, due to previous
statements. Therefore, the main advantage of the extended program check is that the system does
not just examine individual statements for syntactic correctness, but it also examines entire
program sections for semantic errors.
Good Example
The following source code shows the corrected version of the above example. The logical
expression IS ASSIGNED is used (as recommended in the documentation) instead of sy-subrc.
The message from the extended program check could also be hidden using a pragma
(##subrc_read), but this is not recommended in this case because the extended program check
indicates a real problem.
ASSIGN field TO <fs>.
IF <fs> IS ASSIGNED.
...
ENDIF.

You might also like