GUIDELINE 4.12
Global Declarations of a Program
ABAP_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.
ABAP_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.
ABAP_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.
FUNCTION z_handle_screen.
*"------------------------------------------------------
*"*"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.
MODULE user_command_0100 INPUT.
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.
FUNCTION z_handle_screen.
*"------------------------------------------------------
*"*"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.
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved