Skip to Content

Official ABAP Programming Guidelines

The official ABAP Programming Guidelines were presented at TechEd 2009 in Phoenix and were available at the conference book store:


Here is a glimpse of a typical chapter:


All in all, there are around 120 of such rules covering an area that spans from very general subjects like “Separation of Concerns” to very special subjects like “Usage of COLLECT for internal tables”.

The rules are aimed at being reasonable but not dogmatic, profound but not fundamentalist. The compliance with these guidelines should be a given for a developer and not understood as a formalistic necessity.

Alltogether, they are more than just another collection of naming conventions …

You must be Logged on to comment or reply to a post.
  • Hi Horst,

    I consider this book as really important – perhaps it’s the most worthful book I bought within the last months.

    What’s the reason? A lot of ABAPers still believe that they can still code old fashioned way because their old function modules will still compilable. This might be true but those guys are terribly wrong because they won’t be able use their code in any modern environment.

    I want to show this using a practical example. Here the developer decided to define constants in an include program that is included in most of his functions modules:

    CONSTANTS gc_addrguid_zero  LIKE but020-guid
      VALUE '00000000000000000000000000000000'.

    I don't recommend this because you can't control naming conflicts. Better define constants in ABAP interfaces or abstract classes.

    But here is another terrible error because of the usage of LIKE in the definition. There are many reasons not do it and in fact it's forbidden in ABAP OO. So what's the consequence? We can't use this include containing constants in ABAP classes – you can't activate the class.

    I think every ABAPer has to learn that he or she has to follow the SAP guidelines today, otherwise he will to have to change his code in the future. And this will be necessary most likely if wrap out code in model classes to expose them as Web Dynpro applications or within a CRM WebClient application, for example.

    SAP Programming Guidelines help to create modern and stable applications that are ready for SOA and EAI scenarios and new frameworks & technologies SAP ships in next releases resp. enhancement packages.

    Best Regards

    • One way to try and change the behaviour of programmers is not just to say "stop using LIKE statements" but to say "stop using LIKE statments, they are bad because ....." and then the reasons. And just saying that it is bad because it is forbidden in ABAP OO is a circular argument. Rather, it is forbidden in ABAP OO because of the problems it causes such as etc
      I have found that once presented with a sensible reason for doing something even the most dyed-in-the-wool programmer will consider making a change, but just saying "don't do that, do this" and not giving a reason will have no effect at all.

      Cheersy Cheers


      P.S. I have in fact been changing all my LIKE statments to TYPE but when questioned about it by a colleague the only reason I could give was that it was forbidden in ABAP OO. I would be interested to know why in fact LIKE statements are bad.

      • Hi Paul,

        First, that's exactly what we are trying to do: to tell the people why something is bad and not simply that it is bad without giving any reason.

        Second, it's not LIKE itself that is bad but a wrong usage. The addition LIKE is there to refer to the data types of data objects. The addition TYPE is there to refer to standalone data types.

        So, if you refer to data types, you use TYPE, if you refer to data objects you use LIKE (yes, it is so simple). Only for reasons of downward compatibility, you can still use LIKE to refer to one special kind of data types, namely flat structures  from the ABAP Dictionary (including database tables and views)or their components. This is quiet weird and of course obsolete.

        Another question is, whether to refer to data types or to data objects. For this we have a rule: "If a data object directly depends on another data object, directly refer to it using LIKE for the declaration. In all other cases, use TYPE to refer to a standalone data type."

        Kind regards


  • this book is really worth the money and every serious developer should take the time to read it - no matter if you are pretty new to abap or a senior developer.
  • Hi Horst and thanks for an otherwise excellent book that really fills a gap in our company!

    BUT (sorry there is a couple of buts...)

    1. In order to use web dynpro for abap, you have to use portals. There is no display possible (yet) in sap gui! I think that this rule only makes "sense" when there is a (default) sap gui display possiblity - or sap gui is retired all together!

    2. Logical databases in HR seems to be the (unmentioned) special case, where they should be used because of their free selection screens with built-in authorisation checks. For most companies that I know of, HR is very sensitive, and they WANT the security built into the logical database!

    3. You say: don't use COLLECT for standard tables! I totally disagree! COLLECT is still the best way to ensure unique lines in standard tables with char-only fields, and of course one doesn't change the table while building it!

    4. I think there is an exception concerning multiple uses of an include file, i.e. when using IMPORT .. FROM MEMORY / EXPORT TO MEMORY. In this situation I would suggest defining the TYPE, CONSTANTS and variable(s) in an include that can be inserted before the IMPORT and EXPORT statements. In this way you can benefit from the "where used" feature on the memory id constant.

    Otherwise a useful book despite the fact that some of the good examples doesn't follow the rules (p. 29 defines a selection screen outside of a function group...) THANK YOU!

    • Hi Flemming,

      Thanks for your feedback! (No feedback would be kind of spooky; two physicists working part time on programming guidelines simply cannot expect to get everything right from the start ...).

      We will put it to our item list for the next edition.

      Some first (spontaneous) thoughts ...

      Regarding 1:

      In fact, there is a way to call WDA from SAP GUI:

                    URL_TYPE      = 'WDY_APPLICATION'
                    URL           = '0E...' .

      The general usage is questionable, but I found that when placing a WDA in the favorites of SAP Easy Access and debug the call 😉

      Regarding 2:

      What we really need is a replacement of claasical LDB with an objet oriented framework: keeping the good stuff using modern means. But, alas, it was never implemented ...

      Regarding 3:

      Maybe we place an exception there, but in favor of general robustness COLLECT for standard tables is a risk. Especially because it depends on the primary key, which can (by chance) be the standard key, which can even be empty (we'll add something more about usage of (standard) keys in the next edition).

      Regarding 4.

      I don't see, why one cannot declare the memory id constant in a class/interface and use it directly via "ID cl_...=>...". The "where used" also works for for components of classes.

      Kind regards


      • Hi,

        this book is one of my favorits what belongs to clean code development with ABAP. Very nice work! There are a lot of analogies to C. Martins Clean Code Development.

        The main Problem will be the integration of this straight methods to the developers mind. This will take a few years to argue the "old rabbits" into the advantages of this development process.

        By the way regarding Point 1:
        We are violating a WDA Application by using another FuBa to use it via HTML-Control in SAP Gui and it nearly works fine.

              protocol     = protocol
              internalmode = 'X'
              application  = application
              out_url      = l_url
              invalid_application = 1.

        Kind Regards,