Skip to Content

Peer reviews

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.

To report this post you need to login first.

8 Comments

You must be Logged on to comment or reply to a post.

    1. Tobias Trapp Post author
      Hi Thorsten,

      because of this positive feedback I just decided to put this stuff into a presentation for my team and added some examples from the first chapter of Horst Keller’s book “ABAP Fortgeschrittene Techniken und Tools”. This is the one I like most:

      DATA i TYPE I.

      i = 1 / 3 * 2. “Result 0
      i = 11 / 33 * 2.  “Result 0
      i = 111 / 333 * 2.  “Result 0

      i = 11111111 / 33333333 * 2. “Result 0
      i = 111111111 / 333333333 * 2. “Result 0
      i = 1111111111 / 3333333333 * 2. “Result 1 !!

      I think every ABAP programmer should read this book. Especially his warnings concerning data containers in transparent tables are really worth readable.

      Cheers,
      Tobias

      (0) 
    2. Tobias Trapp Post author
      Hi Thorsten,

      because of this positive feedback I just decided to put this stuff into a presentation for my team and added some examples from the first chapter of Horst Keller’s book “ABAP Fortgeschrittene Techniken und Tools”. This is the one I like most:

      DATA i TYPE I.

      i = 1 / 3 * 2. “Result 0
      i = 11 / 33 * 2.  “Result 0
      i = 111 / 333 * 2.  “Result 0

      i = 11111111 / 33333333 * 2. “Result 0
      i = 111111111 / 333333333 * 2. “Result 0
      i = 1111111111 / 3333333333 * 2. “Result 1 !!

      I think every ABAP programmer should read this book. Especially his warnings concerning data containers in transparent tables are really worth readable.

      Cheers,
      Tobias

      (0) 
    3. Tobias Trapp Post author
      Hi Thorsten,

      because of this positive feedback I just decided to put this stuff into a presentation for my team and added some examples from the first chapter of Horst Keller’s book “ABAP Fortgeschrittene Techniken und Tools”. This is the one I like most:

      DATA i TYPE I.

      i = 1 / 3 * 2. “Result 0
      i = 11 / 33 * 2.  “Result 0
      i = 111 / 333 * 2.  “Result 0

      i = 11111111 / 33333333 * 2. “Result 0
      i = 111111111 / 333333333 * 2. “Result 0
      i = 1111111111 / 3333333333 * 2. “Result 1 !!

      I think every ABAP programmer should read this book. Especially his warnings concerning data containers in transparent tables are really worth readable.

      Cheers,
      Tobias

      (0) 
  1. Jurgen Lootens
    Interesting blog.

    Even before SAP moved to OO, they were constantly improving the ABAP language. This effort continued (and was probably accelerated) when OO was introduced.

    I disagree that OO-ABAP is better than straight ABAP. I believe you are comparing apples with pears. Each has its place and purpose.

    In fact, your statement is one that I have come across a lot in academic environments. SAP is used in a business environment where it’s cost-efficiency, ease of maintenance and speed of delivery that matter – not the beauty of the coding paradigm.

    I’ve had many coders work for me. Very often, the ones that go down the OO route create more complexity, higher maintenance code and take longer to deliver stable code. How do you explain that?

    But I have encouraged people to start typing their field-symbols and stop using internal tables with header lines, passing table parameters, etc… stuff which you quote in your blog and which I fully agree with. But this has nothing to do with OO-ABAP.

    (0) 
    1. Tobias Trapp Post author
      You wrote: “Even before SAP moved to OO, they were constantly improving the ABAP language. This effort continued (and was probably accelerated) when OO was introduced.”

      Yes, but in classical ABAP you can still use lots of nasty things which are forbidden in classes: you’ll get activation errors.

      Concerning speed of development I think ABAP-OO is far superior to classical ABAP and I’ll give an example: Using object services it is possible to create an object-relational mappings within seconds. In classical ABAP you’ll have to code a database maintenance layer which is much more error prone and time consuming. And if you start to do performance optimization by keeping business entities in your memory using classical ABAP the effort will even increase.

      You wrote: “In fact, your statement is one that I have come across a lot in academic environments. SAP is used in a business environment where it’s cost-efficiency, ease of maintenance and speed of delivery that matter – not the beauty of the coding paradigm.”

      I made a different experience. The best developers in my team have university background and had only Java skills. After half a year they were able to use OO features in ABAP and their development was up to 3 times faster compared to developers which much more experience in classical ABAP. And in fact those “Java guys” managed to reduce costs of maintenance because they introduces unit tests by covering the code with test classes.

      But I agree with you: a lot of programmers that didn’t learn OO in university or during their training will start to induce unnecessary complexity with OO features. Nevertheless I tell them to use simple ABAP Objects mechanisms and will give two examples.

      The definition of global constants in includes is quite error prone because when having multiple includes you have the risk of naming conflicts which you can’t resolve by activation of the include. Putting constants in interfaces or abstract classes gets much more readable and robust code.

      I recommend using classes instead of function groups. The reason is that in classical ABAP there are only quite limited possibilities to distinguish between “public” and “private” because all function modules are “public”. In this aspect ABAP Objects is much superior and can help to reduce complexity. Another important aspect is global memory of function groups that you can control much more effectively using ABAP-OO.

      My conclusion is: Even a careful use of “modern” object oriented features like classes and interfaces can improve code quality.

      Best Regards
      Tobias Trapp

      (0) 

Leave a Reply