the line 22 and 23 just represent the ABAP code CHECK strlen(&1) >= 5.

We observed after macro line 22 and 23 are executed, our internal table lt is still empty. This is working as expected, since now the APPEND statement in Macro code is not executed yet.

The internal table is filled after Macro code 27 is executed.

before Macro code line 28 is executed, <first> is not valid, since the respective ABAP code READ TABLE &2 ASSIGNING <first> INDEX 1. in line 14 is not executed yet.

click F5, now <first> is filled.

After Macro code 33~35 is executed, the string concatenation is done.

Although you can debug Macro this way, it does not mean you should not think twice when you use Macro in your code. There are already plenty of discussion and blog in SCN regarding how to use Macro wisely. Hope this blog helps you when you have to debug some complex Macro in legacy code.

Regarding the BYTE CODE, if you are referring to the screenshot in my blog, I don’t think it is difficult to understand their meaning since they look something like ABAP command. But if you are referring to code like “xper 06 2F0C 0018 0016 “, I am afraid there is no public documentation on them. Why do we application developer need to understand them? Just out of curiosity? 🙂

I haven’t beforehand but now I have. Well.. I still have the same opinion. The reasons given in this blog or not enough: I disagree with some of them (code readability using macros) and some are not common problems when using ABAP (defining DSL).

My point of view is simple:

1 – They won’t be debugged. Note that to debug a macro you have to know that it exists in your code. What if you set a breakpoint for all “PERFORM”s in code? The ones inside a macro won’t stop the execution of the program. What if you set a watchpoint for a variable changed inside a macro? It will stop way after the macro. Moreover, there are many functional consultants who although are not able to write ABAP code, are able to read and debug it. So when it comes to readability in ABAP, I wear a functional hat and ask myself if a functional would be lost after a piece of code. In case of a macro, definitely he would be lost after a single line of code have changed many variables all at once.

2 – Macros are faster: yes indeed. However based on my experience in 90% of performance issues the most timing consuming code I have founded is within SELECTions in the database and searches inside internal tables. In other words, if you can write good SELECT statements and know how to use other types of internal tables other than STANDARD, it’s very likely your code won’t have any performance problems.

3 – You cannot unit test a macro. And that’s why I don’t use PERFORMs either.

If we want to reuse the same set of statements more than once in a program, we need to include them in a macro. For example, a macro can be useful for long calculations or for writing complex WRITE statements. We can only use a macro within a program in which it is defined. Macro definition should occur before the macro is used in the program.

Macros are designed based on placeholders. Placeholder works like pointers in C language. You can define a macro within the DEFINE…END-OF-DEFINITION statement.

Macrodefinition should occur before the macro is used in the program. Macros are designed based on placeholders. Placeholder works like pointers in C language. You can define a macro within the DEFINE…END-OF-DEFINITION statement.