Skip to Content

Top 10 SAP Coding Practices

A colleague of mine recently asked me what would be the top 10 characteristics of program code that would makes it “best”. I spent a while before I came up with the list, which ended up to be more challenging that I thought, since it only concerned “code” and did not include other aspects of development (analysis, design, validation etc.). I thought this would be good to share, as it can help beginners and may be even others who want to analyse or review programs. I have tried to keep it short and sweet. I hope to blog more on each, in detail later.

So, without any further adieu, my top 10  (in no particular order)


Flexible and Extendable:Code needs to be built for flexibility and extensibility. For e.g., using text elements (keep literals translatable), using configurable tables (like TVARV) instead of hardcoded literals etc.


Current: Code needs to be technically current and obsolete use should be avoided including obsolete functions, obsolete statements, obsolete features (like call dialog) etc. SAP recommended methods should be used as much as possible


Standard & Named right:All programs and objects should only be named in the customer namespace, though some namespaces are not enforced by the system (e.g., Z/Z_ in functions). The names should also be differentiated for local and transportable objects. Programs, objects and code components (subroutines, methods, variables etc.) should follow the naming conventions defined by the SAP IT team and should also follow standard practices followed by SAP


Simple, Readable and Documented: Code has to readable – well named, indented and well constructed. It should be recognizable by using common business programming conventions; and documented well with comments, modification history, modification log etc. Care should be taken to remove any redundant and obsolete comments as well.


Throughput Efficient: Code has to be written and constructed for optimum throughput considering both current and future functionality, load and volume. This would include using the most suitable programming structures and loops, database read options – SQL (using right indexes, select statements), file handling (read by record / read all etc.), internal array reading (using binary search for internal tables) etc.


Reusable, Maintainable & Modular: Code has be designed with best modularity for easy maintenance as well as reusability (subroutines, classes, functions, services, etc.)


Memory Efficient:Code should be built for optimum usage of memory – like reading all records from files / tables vs reading partially, collect and process vs process each record etc.


Robust: Code should be robust to be able to handle unexpected situation and be free of unhandled errors, and retain ACID properties of any updated data – e.g, Runtime errors, exceptions handling


Verified: Code has to be checked and reviewed for common semantic errors using extended programming checks and common coding guidelines (reducing global variables, using local variables and parameters optimally, unicode compliant, dictionary and parameter compliant etc.)


Upgradable:Code should be compatible for upgrades including Unicode compatibility, avoidance of obsolete features, using SAP recommended extension and customization practices, compatible parameter handling etc. 

You must be Logged on to comment or reply to a post.
    • Hello Frank, thank you for the comments.

      I tried not to focus on the functionality that the code delivers, which included security. I appreciate the comment. I will blog on that topic too, hopefully, soon.

      • Wait... what?

        I have to disagree on that.
        Security is specifically NOT a business function, but needs to be addressed at every level of system design as an aspect of the system.
        It's not one certain function or one specific feature that will make your application or system safe and secure - it's the total of all written code and all designed functionalities.

        So, yes, this really should be part of a TOP 10 coding practices.
        Well, at least that's what I think 🙂

        cheers, Lars

        • Lars, yes I absolutely agree to what you say about security 100%.

          What I meant was, without understanding the business functionality, it is hard to build security on a code. But yes, certain security like table authorization group, tcode security etc. can be built based on the security strategy of the team/project.

          When I wrote this, I looked at how one can review a code and rate it, without understanding the functionality of the code. But from your perspective, I agree it is probably important to include "security" as a critical coding practice.

          But what are your thoughts on security that is embedded in the code (org check co.code check etc.) vs outside code (like on tcodes, profiles, roles etc.)? Where do you draw the line? What is a developer's responsibility and what is the analyst's responsibility to specify? Of course, its a joint responsibility, but if you have to draw a line...


  • Create configuration or Z tables to use with your code.  Set up a table maintenance on them.  Create a transaction..  Then you can allow changes to be made on PRD, or made and transported.  That way if something changes your Business Analyst or you will not have to change the code.  Only add or delete an entry from a table. 

    Remember that some of those rules are not used when coding.  Why?  Because there are those pesky end users.  And even though we are not considering design, there are times when these practices have to be ignored based upon requirements.  You may be required to write a program that uses a lot of memory based upon response time.  Efficient - sometimes it is more efficient if we do not allow for a certain selection.  Ah but the requirement requires that selection.  The Efficient part of the rule goes out the window.

    Or ease of reading code - so that maintenance is easier, at that point flexibility may not be a good idea.  Dynamic programming is hard to follow at times.  Sometimes it is good to do it.  And sometimes, it's not worth making it dynamic.  Things are not going to change very often.

    Naming conventions???  Other than saying you have to start things with a Z - I don't believe there should be naming conventions.  Now everyone may disagree.  That's OK, we have naming conventions here at work.  I agree to disagree about that.  Double clicking on the object will tell you what it is without needing a convention. 

    I would say these are excellent guidelines.  But remember there are times when you have to deviate from the guidelines.

    My thoughts,


    • Thanks so much for the thoughts Michelle.

      I completely agree with your thought on dynamic programming. Though it is "cool", it makes impact analysis and tracing / review very difficult. But by "Flexibility" I meant being able to change the default screen input values, fixed values (say company codes, order type) etc. without changing the code. One option is using TVARV table to maintain these, and the other of course, is exactly what you said - using Z tables to maintain these and make it configurable.

      And yup, the users always throw in a wild card, and all our guidelines go for a toss 🙂

      Naming conventions are somewhat important for a bunch of reasons. a. it can give a clue as to which functional area own that objects (programs/tables) which helps in reporting, when you don't maintain a directory (many customers don't or can't really keep it updated); b. gives an indication of the kind of program (form driver, interface, report enhancement etc.); c. You may need a clue as to where it came from - a customer XYZ's objects can be ZXYZ_* and when they buy tools or application from other vendors (say VXY), it can be ZVXYZ_* etc. It canbe very helpful, especially the customers have multiple organizations sharing the SAP environment.


  • Thanks for the blog.  Perhaps you should add ...

    'Optimized for HANA'

    Only kidding.  But on the other hand, one does wonder specifically what coding practices might need to change, or even turn 180 degrees in the future to be 'best practice' for HANA.  For instance, the general rule to limit DB accesses might not apply with HANA.  It is early days I know, but we also know code can last for years.  We would all love to know what coding practices might be more compatible with a HANA future.