Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results forÂ
Search instead forÂ
Did you mean:Â
Success! Subscription added.
We have launched new Developer forums/groups in the SAP Community. If you are here to publish developer- or SAP-technology related blog posts, please check out our new groups instead. You can find more information about the developer forums in this What's New post.
Thank you for your information. I just tried in my system, and I could not debug the macro using system debugging. Would you please kindly share how you achieve that?
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? :smile:
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.