Functional programming in ABAP – immutable variables

I know the title is confusing – of course no functional programming is possible in ABAP. But lately I read a bit about it and I try to adopt some things that seem useful to me. When I read about immutable objects or pure functions (no side effects) for the first time, It seemed very strange to me. In fact, going back to BASIC programming in school, the possibility to change a variable seemed to be the key capability of a computer program. But immutable does not seem that a variable is a constant – it can have different values every time the program runs. But during one run, it is only set once.

Applying this technique, we maybe have to use much more variable declarations as before, so what do we get in return for this effort`?

Look at this code snippet:

    types:
      begin of lty_s_material,
        material type string,
        description type string,
      end of lty_s_material,
      begin of lty_s_bom,
        header type lty_s_material,
        component type lty_s_material,
      end of lty_s_bom,
      lty_t_bom type standard table of lty_s_bom with default key.

    data(ls_material) = value lty_s_material(
      material = 'COMP'
      description = 'Computer' ).
    data(lt_bom) = value lty_t_bom(
      ( header = ls_material
        component = value #( material = 'SCR'
                             description = 'Screen' ) )
      ( header = ls_material
        component = value #( material = 'CPU'
                             description = 'Central processing unit' ) )
      ( header = ls_material
        component = value #( material = 'KYBD'
                             description = 'Keyboard' ) ) ).

    cl_demo_output=>write( 'Components of material :' && ls_material-material ).
    " fetch the first component
    ls_material = lt_bom[ 1 ]-component.
    cl_demo_output=>write( '1st Component :' && ls_material-material ).
    ls_material = lt_bom[ 2 ]-component.
    cl_demo_output=>write( '1st Component :' && ls_material-material ).
    ls_material = lt_bom[ 3 ]-component.
    cl_demo_output=>write( '1st Component :' && ls_material-material ).

    cl_demo_output=>display( ).

Here, I reuse a variable (ls_material) many times for different data sources. If you imagine this to be a real program with some more lines, this gets very confusing for a human that reads it. To figure out what ls_material stands for, one has to find always the last value assignment.The problem increases enormously when variables are global and can be changed throughout all methods (see The Global Variable Dilemma).

To avoid all this confusion, it’s better to use different variables

    data(ls_header_material) = value lty_s_material(
      material = 'COMP'
      description = 'Computer' ).
    data(lt_bom) = value lty_t_bom(
      ( header = ls_header_material
        component = value #( material = 'SCR'
                             description = 'Screen' ) )
      ( header = ls_header_material
        component = value #( material = 'CPU'
                             description = 'Central processing unit' ) )
      ( header = ls_header_material
        component = value #( material = 'KYBD'
                             description = 'Keyboard' ) ) ).

    data(ls_first_component) = lt_bom[ 1 ]-component.
    cl_demo_output=>write( '1st Component :' && ls_first_component-material ).
    data(ls_second_component) = lt_bom[ 1 ]-component.
    cl_demo_output=>write( '1st Component :' && ls_second_component-material ).
    data(ls_third_component) = lt_bom[ 1 ]-component.
    cl_demo_output=>write( '1st Component :' && ls_third_component-material ).

In this snippet, the variable names already reflect very well what they stand for and no variable is overwritten.

Of course, with the new expressions that ABAP introduced from 740 on, variable creation itself can be avoided:

    cl_demo_output=>write( '1st Component :' && lt_bom[ 1 ]-component-material ).
    cl_demo_output=>write( '1st Component :' && lt_bom[ 2 ]-component-material ).
    cl_demo_output=>write( '1st Component :' && lt_bom[ 3 ]-component-material ).

And this is, what I try to do as often as possible. A good variable is a variable that will not change. A better variable is no variable at all 🙂

Of course you can not always avoid changing a variable. It is often necessary when building sums in loops or when you count something. But if you keep in mind that you possibly do not want to change variable values after having them set once, you will get more robust code.