ABAP Keyword Documentation →  ABAP Programming Guidelines →  ABAP-Specific Rules →  Checks for Correctness → 

Syntax Check

Background

The syntax check provides syntax errors and syntax warnings:

The severity of the ABAP syntax check is determined by the decisions that were made when the program was created. In this way, program constructs that produce only syntax warnings outside of classes or in non-Unicode programs, can represent real syntax errors in classes or in Unicode programs. You can suppress selected syntax warnings by using pragmas. A pragma is a program directive that affects specific checks but does not influence the program flow.

The operational package concept means that the syntax check also checks package violations. In this case, whether a syntax error or only a syntax warning occurs depends on the encapsulation level set for the corresponding package.

Rule

Take notice of syntax warnings

Take all warnings of the ABAP syntax check seriously. Syntax warnings are not permitted in completed programs.

Details

You must always correct the causes of syntax warnings because they generally lead to unpredictable errors. These warnings are often reclassified as errors by SAP in subsequent AS ABAP releases. In this case, a program that initially only included syntax warnings is syntactically incorrect and can no longer be used after an upgrade. Exactly the same behavior is displayed when switching from non-Unicode programs to Unicode programs or when migrating older program parts to ABAP Objects.

Selected syntax check warnings can be hidden using pragmas. With respect to the package check, selecting Package Check as Server in Package Builder is the first step to achieving real encapsulation.. It enables users of development objects to modify their where-used positions before hard syntax errors occur. For this reason, all package check warnings must be corrected to ensure that the program's syntax remains correct, even after increased encapsulation of the packages used.

Bad example

The following source code causes a syntax warning. An internal table is accessed using a freely specified key, even though a secondary key with the same components exists. This access performs a linear search.

FIELD-SYMBOLS <fs> TYPE spfli.

DATA itab TYPE HASHED TABLE OF spfli
          WITH UNIQUE KEY carrid connid
          WITH NON-UNIQUE SORTED KEY cities COMPONENTS cityto cityfrom.

...

READ TABLE itab WITH KEY cityfrom = '...' cityto = '...'
                ASSIGNING <fs>.

Good example

The following source code corrects the above example. Here, the secondary key is used to access the table. The access performs a binary search. Hiding the syntax warning using the associated program primkey is not recommended here.

FIELD-SYMBOLS <fs> TYPE spfli.

DATA itab TYPE HASHED TABLE OF spfli
          WITH UNIQUE KEY carrid connid
          WITH NON-UNIQUE SORTED KEY cities COMPONENTS cityto cityfrom.

...

ASSIGN itab[ KEY cities
             COMPONENTS cityfrom = '...' cityto = '...' ] TO <fs>.