Skip to Content
Author's profile photo Christian Drumm

How to Shoot Yourself in the Foot with DATA

Hi all,

I recently read JavaScript Allongé by Reginald Braithwaite ( It contains a section on “How to Shoot Yourself in the Foot with Var” in the context of discussing variable bindings and references in JavaScript. In particular the following code snippet is presented:

var questionable = 'outer';
(function () {
     return questionable;
     var questionable = 'inner';

In contrast to what one might expect, this code returns undefined. In JavaScript the var statement acts as if it had been declared at the beginning of the function. When reading this I immediatly wondered what the result of similar code in ABAP would be as I knew that the DATA keywords behavior is similar.

First Shot – Missed

In order to test how ABAP would behave I wrote the following little test report.

    DATA:         test_data TYPE string VALUE '1234'.
    METHODS: test RETURNING value(v) TYPE string.
  METHOD test.
    v = test_data.
    DATA test_data TYPE string VALUE 'ABCD'.
  DATA: impl TYPE REF TO lcl_test,
        s    TYPE string.
  s = impl->test( ).
  WRITE: s.

With this report I tried to duplicate the JavaScript code shown above. The report defines a local class (lines 3 to 7) with a single attribute test_data and one method test. The method simply returns the value of the attribute / local variable test_data (lines 10 to 15). Finally the local class is instantiated an the result of the method invocation is written to the screen.

I expected this code to print ABCD. However, executing the report actually prints 1234. Although there is a local variable test_data defined in the method, the method returns the value of the attribute. So in this case, the In then attribute doesn’t seem to be hidden by the local variable. However, in the debugger I get the following view:


As I expected, the local variable is already defined when the assignment in line 12 (line 23 in the screenshot) happens.

Second Shot – Hit

The next thing I tried is to change the method implementation of the method test to this:

 METHOD test.
    IF 1 = 0.
      DATA test_data TYPE string VALUE 'ABCD'.
    v = test_data.

When the report is executed now it prints ABCD!


So what is the result of this experiment? In ABAP the DATA keyword seems to create variable with a rather peculiar scoping. Their are neither global (to the method or function) nor local (to a code clock like an IF) but rather something in between. It seems to be that the sequence of the compiler parsing the source determines the scope of a variable. However, I’d really like to discuss this with somebody understanding the ABAP compile in detail. Maybe this is just a artifact of this particular test.

In  summary I think that the little experiment underlines the importance of sticking to the well known best practices of:

  • defining all variable at the beginning of a program, method or function
  • referencing instance attributes using me-><variable_name> and class attributes using <class_name>=><attribute_name>

when writing ABAP code.


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Iftah Peretz
      Iftah Peretz

      Very interesting! I'm going to check this when I get back to the office. I think that the 'return' key word makes the compiler ignore whatever follows it, where as in the second try you made it is creating it(the var. test_data) in a local scope and then returning it, even thou it shouldn't because the 'if' condition did not happen.

      Author's profile photo Christian Drumm
      Christian Drumm
      Blog Post Author

      Hi Iftah,

      actually the return key word doesn't change the behaviour. I also tried this without the explicit return. The behaviour was the same as when the return was included.