ABAP Keyword Documentation → ABAP Programming Guidelines → Robust ABAP → Modularization units
Type of Formal Parameters in Procedures
Other versions: 7.31 | 7.40 | 7.54
Background
The parameter interface of a procedure consists of formal parameters and specifies the exceptions possible in the procedure. The possible types of formal parameters are:
- Input parameters
Defined usingIMPORTING
in methods and function modules and usingUSING
in subroutines.
- Output parameters
Defined usingEXPORTING
in methods and function modules.
- Input/output parameters
Defined usingCHANGING
in methods, function modules, and subroutines.
- Return codes
Defined usingRETURNING
in methods.
The actual behavior of a formal parameter, however, is in part determined by the combination of the parameter type and the pass by type.
Rule
Choose the appropriate formal parameter type
Select a formal parameter type that corresponds to the parameter semantics:
- Input parameters for parameters that are evaluated but not changed in the procedure.
- Output parameters or return codes for parameters that are not evaluated but changed in the procedure.
- Input/output parameters for parameters that are evaluated and changed in the procedure.
Details
For the consumer of a procedure, the parameter types provide important information about how they are used in the procedure and leads the user to expect the procedure to behave in a certain way. If an unsuitable parameter type is selected, the risk of inappropriate use increases.
- Input-only parameters should always have the
IMPORTING
type (or USING for subroutines). Be aware that, when using pass by reference, writes performed on an input parameter defined usingUSING
are possible without a syntax error being produced (as is the case with input parameters of methods or function modules defined usingIMPORTING
). Yet another reason to not use subroutines.
- Output-only parameters should always be
EXPORTING
orRETURNING
.
- Parameters that are received and changed should always be of the
CHANGING
type. In particular, in a procedure (method) the fact that anEXPORTING
parameter (or aUSING
parameter in the case of subroutines) passed by reference behaves (from a technical perspective) like aCHANGING
parameter should not be exploited.
Input parameters or input/output parameters that are not necessarily required for the execution of a
procedure should be defined as optional by using OPTIONAL
or by specifying
a DEFAULT
value. Otherwise, calling programs are forced to pass unnecessary parameters and create helper variables especially for this purpose.
A narrow parameter interface in line with a procedure with an appropriate number of statements only requires a few input parameters and one return value. However, this cannot really be applied consistently in practice and is therefore not set out as a rule here.
Note
Another parameter type are table parameters that can be declared for function modules and subroutines
using TABLES
. Basically, they have the same effects as input/output parameters for internal tables. This parameter type is obsolete and should no longer be used.
Bad Example
The following source code shows a formal parameter that is declared as an output parameter using
EXPORTING, but is used in the method like an input/output parameter declared with CHANGING
. This does not correspond to the semantics that a calling program expects.
CLASS class DEFINITION.
PUBLIC SECTION.
METHODS do_something
EXPORTING e_parameter TYPE ...
ENDCLASS.
METHOD do_something.
"evaluate e_parameter
...
"set e_parameter
...
ENDMETHOD.
ENDCLASS.
Good Example
The following source code corrects the above example by declaring the parameter as an input/output parameter with CHANGING
according to its use.
CLASS class DEFINITION.
PUBLIC SECTION.
METHODS do_something
CHANGING c_parameter TYPE ...
ENDCLASS.
METHOD do_something.
"evaluate c_parameter
...
"set c_parameter
...
ENDMETHOD.
ENDCLASS.