ABAP Keyword Documentation → ABAP Programming Guidelines → Structure and Style → Program Structure and Procedure Structure
Global Declarations of a Program
Other versions: 7.31 | 7.40 | 7.54
Background
Each ABAP program has a global declaration part where you can declare data types, interfaces, classes, and data objects that are visible throughout the program.
From a technical viewpoint, the global declaration part consists of all declarations that cannot be
assigned to a more local context (class, procedure). All declarations implemented in processing blocks
without their own contexts (in event blocks and dialog modules) and declarations declared between completed
processing blocks are assigned to the global context. Event blocks of GET
and AT SELECTION-SCREEN events are exceptions. Variables declared here are only valid in the event block.
In an ABAP statement, you can only ever refer to the previous declarations of the currently visible contexts.
Rule
Implement global declarations centrally
Place the global declaration part of a program at a central, context-related point at the beginning of the program.
Details
You should only use the area between the introductory statement of an ABAP program and the first implementation as the global declaration part. This the only place where you should implement global declarations in a meaningful sequence. This ensures that the declarations intended for global use can really be used in all subsequent implementations.
There should not be any declarative statements in contexts that do not support local data (provided that they are still used). Otherwise, a false impression of local validity is created when the program is read, which may lead to the program not being correctly understood.
You only need to deal with this rule explicitly if you work with program types other than class or interface pools. The Class Builder implicitly specifies which declarations occur and where. These are the declarations of the global class/global interface itself as well as optional local data types, classes, and interfaces in class pools. The developer cannot directly access the main program of a class pool or interface pool. This is still the case even if the source-code-based Class Builder is introduced, because it only shows the declaration and implementation of the global class.
For other program types (subroutine pools, function groups, and executable programs), the developer can access the entire main program. If you work with these program types, you must ensure that the rule is adhered to yourself. The top include can help you do this. It is especially suited to all programs that are organized using include programs. The top include is specially designed for the global declaration part and is therefore supported by the ABAP Workbench and ABAP Compiler. The ABAP Workbench enables you to automatically create and integrate the top include. The Compiler incorporates the relevant top include into the syntax check for an individual include program. This enables you to perform meaningful syntax checks of individual include programs.
If the top include is available, it should always be the first include program that a main program incorporates.
The top include can also contain additional INCLUDE statements. The top include, and any include programs incorporated in the top include, can only contain declarations and not implementations.
If you mainly work with ABAP objects, the global declaration part or the top include should only contain declarations of local classes and interfaces, if the above rule is strictly adhered to. Data types should only be declared for classes and interfaces or in the ABAP Dictionary. Global data objects are only required for communication with classical dynpros. Therefore they should only be used in the top include for function groups that encapsulate classical dynpros.
Exception
The above rule can be mainly justified due to the visibility within the program and the validity of declarations. Strictly speaking therefore, it only applies to program types other than class pools. In class pools, the visibility outside of the class pool and the resulting dependencies are also important.
A further exception occurs in the following situation: the local classes of a program are relatively independent units and their implementations do not refer to the declarations of other local classes. In this case, you can list your declaration and implementation parts one after the other to improve readability.
Bad example
The following source text shows a function group for encapsulating a classical dynpro, after the include
programs have been resolved. The two dialog modules contain data declarations that look like local declarations
but have global validity. You can only statically access this type of data object below the declaration,
so that the function module has no access to g_input_field, and the PBO module has no access to g_ok_code.
FUNCTION-POOL z_screen.
DATA g_start_value TYPE c LENGTH 20.
*"------------------------------------------------------
*"*"Local Interface:
*" IMPORTING
*" REFERENCE(i_start_value) TYPE csequence OPTIONAL
*"------------------------------------------------------
g_start_value = i_start_value.
CALL SCREEN 100.
ENDFUNCTION.
MODULE status_0100 OUTPUT.
DATA g_input_field TYPE c LENGTH 20.
g_input_field = g_start_value.
ENDMODULE.
DATA g_ok_code TYPE sy-ucomm.
CASE g_ok_code.
WHEN '...'.
...
ENDCASE.
ENDMODULE.
Good example
The following source code shows the function group from the above example, after the global declarations
have been moved to a coherent global declaration part that follows the introductory statement. The additional
global data object g_start_value is no longer required, and you can access g_ok_code in the PBO module.
FUNCTION-POOL z_screen.
DATA: g_input_field TYPE c LENGTH 20,
g_ok_code TYPE sy-ucomm.
*"------------------------------------------------------
*"*"Local Interface:
*" IMPORTING
*" REFERENCE(i_start_value) TYPE csequence OPTIONAL
*"------------------------------------------------------
g_input_field = i_start_value.
CALL SCREEN 100.
ENDFUNCTION.
MODULE status_0100 OUTPUT.
CLEAR g_ok_code.
ENDMODULE.
MODULE user_command_0100 INPUT.
CASE g_ok_code.
WHEN '...'.
...
ENDCASE.
ENDMODULE.