GUIDDELINE 6.38
Type of Formal Parameters in Procedures
ABAP_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 parameter
Defined with IMPORTING in methods and function modules and with
USING in subroutines.
Output parameter
Defined with EXPORTING in methods and function modules.
Input/Output Parameters
Defined with CHANGING in methods, function modules, and
subroutines.
Return codes
Defined with RETURNING in methods.
The actual behavior of a formal parameter, however, is in part
determined by the combination of the parameter type and the
transfer type .
ABAP_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.
ABAP_DETAILS
For the user of a procedure, the parameter types provide important
information on how they are used in the procedure and leads the user to
expect the procedure to behave in a certain way. If you do not select a
suitable parameter type, this increases the risk of an inappropriate
use.
Pure input parameters should always have the IMPORTING type (or
USING for subroutines). Be aware that when using pass by
reference, write access to an input parameter defined using USING
is possible without a syntax error being produced (as is the case with
input parameters of methods or function modules defined using
IMPORTING ). Yet another reason to not use subroutines.
Pure output parameters should always be of the EXPORTING or
RETURNING type.
Parameters that are received and changed should always be of the
CHANGING type. In particular, in a procedure (
method ) you should not exploit
the fact that an EXPORTING parameter (or a USING parameter
in the case of subroutines) passed by reference
behaves (from a technical
perspective) like a CHANGING parameter.
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.
CLASS class IMPLEMENTATION.
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.
CLASS class IMPLEMENTATION.
METHOD do_something.
"evaluate c_parameter
...
"set c_parameter
...
ENDMETHOD.
ENDCLASS.
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved