Skip to content

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 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.

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 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.