Refactoring an old report - some strange code explained

[joachimrees1]

Not sure how to start this, so I'll jump right in:

in the past I was tasked to re-factor an old (first line coded > 15 years ago) but still relevant report. Recently I came back to it an found code like that:

DATA: l_atp_stock_fka_lagerbestand LIKE lagerbestand.



l_atp_stock_fka_lagerbestand = get_verfuegbar_atp(

i_werks = l_marc-werks

i_matnr = l_marc-matnr ).



lagerbestand = l_atp_stock_fka_lagerbestand.

A new variable B is defined LIKE an existing variable A.
Then B is filled by a method call.
Then A is filled from B.
(Not in picture: there is no further use of B!).

Looking through version history (and my mind - after a short irritation, I was pretty sure why I did this!) shows why:

At one point in time, the code looked like this:

PERFORM get_verfuegbar USING l_marc-werks l_marc-matnr

CHANGING lagerbestand.



DATA: l_atp_stock_fka_lagerbestand LIKE lagerbestand.



l_atp_stock_fka_lagerbestand = get_verfuegbar_atp(

i_werks = l_marc-werks

i_matnr = l_marc-matnr ).



lagerbestand = l_atp_stock_fka_lagerbestand.

Explanation: Being very old, this report used lots of FORM / PERFORM.
Refactoring it, I changed that to using method calls wherever possible.

Of course, I wanted to make sure the new code would produce the same result as the old one.

This is what that construct allowed me to do:

The new code would always "win" as it would overwrite what was calculated in the old code.
But I also had the possibility to set a breakpoint and compare those results in the debugger.

(I think I didn't, but I could even have added an ASSERT-Statement).

So that's the story of this little piece of code.

I now change it to simply look like this:

lagerbestand = get_verfuegbar_atp(

i_werks = l_marc-werks

i_matnr = l_marc-matnr ).

-> so that story would be hidden deep in version history had I not shared it here.

What do you think?
Had you similar encounters?
Would you have chosen a different way?

best
Joachim