SAP DECLARATION VARIABLES GUIDL documentation, setup help and example usage

GUIDELINE 6.3

Declaration of Variables

ABAP_BACKGROUND
Variables can be declared in the following contexts:

Cross-program: as attributes of global classes and interfaces

Program-local:

in the global declaration part of a program

As attributes of local classes and interfaces

In procedures ( Methods )

Variables that are declared within most of the event blocks or dialog modules as well as between completed processing blocks also belong to the global declaration part of a program, but violate the rule implement global declarations centrally .
Program-local variables that are declared in the global declaration part of a program are generally referred to as global variables .

ABAP_RULE
Do not declare global variables
Do not declare variables in the global declaration part of a program. Variables may only be declared as attributes of classes and interfaces or locally in methods.

ABAP_DETAILS
This rule is directly derived from the basic rule use ABAP objects . If you disregard helper variables in procedures (
methods ), the content of the variable of a program indicates the state of the program and consequently the state of an application. In object-oriented programming, the class replaces the program, and the state of an application is no longer the state of the programs but the state of the classes or objects.
Furthermore, the rule exploit the benefits of encapsulation also assumes a critical role. The data of an application is sufficiently protected from misuse only in the visibility sections of classes.
Except for the following exception, you should not declare any global variables in a new ABAP program. They indicate a poor programming style that disregards proven concepts such as task sharing and encapsulation. If you need to access the same data of a program from multiple local classes and interfaces, you must create them in an appropriate visibility section of a local class or an interface. These can also be local classes or interfaces that contain nothing but such attributes.

Note
The above rule also applies to the declaration of field symbols with the
FIELD-SYMBOLS statement.

Exception
If you still use classical dynpros and selections screens instead of Web Dynpro ABAP , global variables are required as interfaces for the communication between ABAP and classical dynpros. Global variables can be declared using the following statements for this purpose alone:

DATA , TABLES and

CONTROLS for general dynpros

PARAMETERS and SELECT-OPTIONS for selection screens

In these cases, you have to ensure the maximum possible encapsulation of those global variables.

Bad example
The following source code shows the top include of a function group for document display. In addition to the required interface work area, which is declared with TABLES , further global variables exist that indicate the state of the display. However, according to the above rule, you are not allowed to use global variables for purposes other than communication with a classical dynpro.
FUNCTION-POOL show_documents.
TABLES document_structure.
DATA: g_language TYPE sy-langu,
g_display_mode TYPE ...
...
CLASS screen_handler DEFINITION.
PUBLIC SECTION.
...

Good example
The following source code shows an improved example. The previously global variables are encapsulated in a class that is specifically provided for the state of the display, and can be addressed using
display_status= in the other classes of the program.
FUNCTION-POOL show_documents.
TABLES document_structure.
CLASS display_status DEFINITION.
PUBLIC SECTION.
CLASS-DATA: language TYPE sy-langu,
display_mode TYPE ...
...
ENDCLASS.
CLASS screen_handler DEFINITION.
PUBLIC SECTION.
...

Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved