My list of favourite ABAP bugs
In my opinion software reviews are necessary in software development especially if programmers are new to ABAP and have limited skills in that language. But surprisingly I had to learn that code reviews are even more important if the software developers have long ABAP experience.
I think you know that guys who know every detail of ABAP/4, who love internal tables with header lines and TABLES parameters? Often they don’t like new paradigms like object orientation and they tell you that they developed R/3 code their whole life and that they don’t have to change their programming habits because SAP won’t give up supporting obsolete technology.
I don’t want to discuss issues of programming style and paradigms in software development. I only want to show that their programming style is very confusing and that there are good reasons to adopt current SAP programming guidelines. The best reason is of course that code written in old-fashioned way won’t run in higher releases.
Do you know the solution?
Last days I had to check code written under 4.6C that should to run under release 6.20. Unfortunately ABAP 4.6C isn’t that restrictive as in higher releases. In this small weblog I want to present my favourite bugs I found during code inspections. I hope you like it.
Question: What’s the difference between those two statements?
Solution: The first one ist correct. In the second case the TABLE statement was missing and the insert was performed at index sy-tabix which is desastrous.
Question: Can you predict the result of both code fragments?
Solution: In the first case you get an output because <fs> isn’t typed, so it is assigned to SPACE.
Question: Can you recognize immediately why following code can’t is syntactically worng?
OK, this was too easy. TABLES doesn’t work with non-standards tables. But what happens if you enclose the call of the form do_something? Again I expect an answer for both definitions:
The solution is simple: z_test_1 can’t be translated because the parameter I_TABLE can be a non-standard table. The compiler can’t check that in z_test_2. As a consequence you will get a runtime error if i_table is a non-standard table.
Question: What’s the behaviour of both code samples in ABAP 6.20?
Solution: This first snippet of code is an example of that doesn’t get translated in ABAP 6.20 compared to 4.6C. You can use the second statement for example to perform that delete.
I use that example together with following code to show differences between ABAP 4.6C and Release 6.20:
This leads to a syntax error in release 6.20.
What can we learn?
I will tell nothing.new. You can improve software quality quite easily:
- Learn ABAP Objects – ABAP/4 won’t help you any longer.
- Search the online documentation for obsolete statements.
- Use the Code Inspector.
- Use transaction uccheck to detect wrong MOVEs and parameter passes in your code.
What are your favourite bugs?
If you are a SDN member I expect that you are open minded and that you know the advantages of ABAP Objects and object orientation in general. So you won’t use an very old fashioned programming style. But I guess you have good reasons for doing so and that you can add further examples of bad programming styles to that small list above.