Data declaration within IF statement

[Former Member]

Hi all,

I'm looking at someone else's code where it follows the pattern :

IF x = y.

DATA: lv_abc TYPE i.

.... additional processing...

ENDIF.

ABAP does of course allow the above, but unless it's an inline declaration (which this isn't), I find DATA declaration inside an IF statement a little strange. Any comments on best practice regarding this ?

[retired_member]

https://help.sap.com/http.svc/rc/abapdocu_752_index_htm/7.52/en-US/index.htm?file=abenlocal_declar_g...

[matt]

I used to do near-to declaration.

I read your help text and was unconvinced by the argument in the body. Surely only a crazy programmer would deliberately access variables before they're declared. It all seemed rather woolly. It was until I looked at your "bad example", after that I changed my mind. That example has convinced me why near-to-use declaration isn't safe.

I think the help text needs to be updated so the possibility of the "bad example" is explained early on - because that is the killer argument.

[retired_member]

I must admit, the whole thing is a little bit hairy.

Some ten years ago, I was a true advocate of the strict rule, local declarations only at the beginning and only programmed according to the rule. Reason: the trap described in the text and the problem shown in the bad example.

Nowadays, with inline declarations, it is hard to follow the rule and to keep the strict line.

So, maybe nowadays we could write the good example also as

METHOD main. 
   
  ... 
  
  DATA number TYPE i.
  DO 10 TIMES. 
     number = 10. 
    ... 
    "number = 11, 12, 13, 14, ... 
     number = number + sy-index. 
    ... 
  ENDDO. 
  ... 
ENDMETHOD. 

placing the declaration near to the loop but not inside it.

Of course, the trap described in the guideline - visibiltiy vs. validity - remains and one must be quite disciplined in using the local data.

In fact we have the problem, that the ABAP syntax became more modern with inline declarations, but since we don't have local visibility in control structures or even expressions, the old traps remain. Not simple to phrase a clear guideline in that situation. Modernists say, the current guideline is outdated. Responsible people might say, it is good to still point out the traps.

[matt]

I get round the bad example - which is a trap I've fallen into - by using

METHOD main. 
  ... 
  DO 10 TIMES. 
    "    DATA number TYPE i VALUE 10.
    DATA(number) = 10. 
    ... 
    "number = 11, 13, 16, 20, ... 
    number = number + sy-index. 
    ... 
  ENDDO. 
  ... 
ENDMETHOD.

If number must be some other type, not identifiable directly from the value, I just use CONV.

For some of my clients, the standards say we can use inline declarations, but others must go at the top. So I make it my practice to use inline declarations whereever possible!

Since using inline declarations, it's become clearer to me that we often re-use variables even within a method. A sort of global local variable - things like "count". Now I use count_doc and then count_item or suchlike. I try to make sure that a variable is used for one purpose only.

Are there any traps to fall into with field-symbols with near declaration?

[retired_member]

"Are there any traps to fall into with field-symbols with near declaration?"

Don't think so, no dynamic access.

[retired_member]

"I get round the bad example"

Nice one. Will add it to the document.