Skip to content

ABAP Keyword Documentation →  ABAP Programming Guidelines →  Structure and Style →  Formatting the Source Code. 

Using the Pretty Printer

Other versions: 7.31 | 7.40 | 7.54

Background

The alignment of ABAP statements in the source code is not specified syntactically. There should be a maximum of one statement per line, which can be technically indented and wrapped as required. This makes control structures visible. By inserting blank lines, you can group related source code sections, which makes the code easier to read. Note that in ABAP statements, blank characters cannot be added or left out at random. For example, tokens must be separated by at least one blank character (especially with operands and operators). In a method call, no blank characters are permitted between the name of the method and the left bracket.

Languages with a C-like syntax (where statement blocks within control structures are delimited by curly brackets) provide an inexhaustible source for discussions on how to best make indentations. However, for ABAP the solution is obvious: Every introductory statement (such as IF) has an associated concluding statement (in this case, ENDIF). Event blocks for ABAP runtime environment events are the only exception here. They are introduced by a statement (such as START-OF-SELECTION) but are not concluded with the associated concluding statement. Instead, they are concluded with the next event block. However, event blocks should only be used in exceptional cases. Introductory and concluding statements are aligned at the same level; the block content is indented.

The Pretty Printer can modify the indentation of control structures and the capitalization of keywords and names in the source code at any time (even in display mode).

Rule

Pretty Printer consistently and universally

Use the Pretty Printer to format your source code consistently. If the Pretty Printer cannot format the code as required, you need to make manual changes.

Details

We recommend that you use the Pretty Printer to make indentations that are absolutely necessary to make the source code easy to read. This guarantees that the indentations are consistently based on the logical control structure and that the indentation depth is identical for each program. Implementing this type of formatting by hand is prone to errors and not recommended.

Even though with the Pretty Printer you can adapt the source code to any other style (using the available settings), you should select a consistent and universal style. The reason for this is that version management and the correction workbench are not designed to ignore purely stylistic differences between source code versions. Therefore, the following Pretty Printer settings are recommended for consistent source code formatting. These settings cover the expectations and working habits of most ABAP developers:

  • Do not insert standard comments
    The standard comment only contains redundant information and it is not adapted, if the source code is changed.
  • Keyword Uppercase
    Makes it easier to understand the source code in printed form. In this case, syntax color-coding is usually not visible.

You need to manually edit the code, to ensure the correct use of blank lines between related source code blocks. Syntactic units, such as classes, methods, control blocks, or semantic units of a program, should be separated from one another with one or two blank lines (depending on their size and meaning). However, there should not be more than two blank lines in succession.


Note

We recommend that you use the Keyword Lowercase setting in the Pretty Printer, for reasons of visual clarity. This is because repository object names and data objects names in the ABAP Debugger are displayed in uppercase, in all tools required for ABAP development. With the Keyword Lowercase setting, the source code format matches this display format. For example, reading COLUMN columns form a DBTAB database table:

select COLUMN1 COLUMN2 ...
       from DBTAB
       into corresponding fields of ITAB
       where COLUMN = FIELD.

Names in uppercase are also more suitable because many dynamic operand positions in ABAP still require uppercase. A good example is an almost static call of function modules. With the Keyword Lowercase setting, the call of a function module FUNCTION_MODULE would be as follows:

call function 'FUNCTION_MODULE' exporting PARAMETER = FIELD.

However, the Keyword Lowercase setting was added to the Pretty Printer relatively late and could not compete against the more common setting Keyword Uppercase. In addition, the ABAP syntax diagrams and sample programs in ABAP documentation, as well as all relevant publications, are formatted with the Keyword Uppercase setting. If we recommended the use of the Keyword Lowercase setting, this would lead to confusion and would not help the programming guidelines to be universally accepted.

Bad Example

The following source code shows the above example, but without indentations and only with lowercase. The highlighted ABAP words (shown in bold here and in color in the ABAP Editor) might not appear in a program printout. This would make the program even less legible.

class class definition.
public section.
methods meth.
endclass.
class class implementation.
method meth.
data: itab type table of dbtab,
wa type dbtab.
select *
from dbtab
into table itab
where column = ' '.
if sy-subrc <> 0.
return.
endif.
loop at itab into wa.
...
endloop.
endmethod.
endclass.