Official ABAP Programming Guidelines

Official ABAP Programming Guidelines [As per SAP Documentation]:

ABAP Programming Guidelines as per the official SAP documentation consists of the following major points:

Follow the KISS principle:

KISS is an acronym and can have any of the following meanings (the list is not exhaustive):

  • Keep it simple, stupid.
  • Keep it small and simple.
  • Keep it sweet and simple.
  • Keep it simple and straightforward.
  • Keep it short and simple.
  • Keep it simple and smart.
  • Keep it strictly simple.
[Add on: I will say follow KISS ASS principle, i.e. Keep It Short, Smart and Strictly Simple]

Have less nesting depth:

It means try not to write loops under loops or Select Query / SQL commands under loop statements. It affects the execution badly.

Follow the SoC principle:

  • Follow the separation of concerns principle. As a result, the software:
  •  is more stable
  • easier to understand
  • can be reused more easily
  • easier to transport
  • has better maintenance
  • can be tested more easily

It can be as simple as keeping data declarations and the implementation of the functions separate to keeping different segments of codes under different methods of a class for better understanding.

Comply with or check compliance with existing product standards:

Adhere to the product standards that exist in your organization, and ensure the correctness and quality of your programs by testing them during development and after completion with all the test tools at your disposal.

As part of this basic rule, we recommend that you use all available tools that help to ensure the correctness and quality of ABAP programs and follow the ABAP programming guidelines.

ABAP Programming Guidelines

  • Include the extended program check(transaction code is SLIN) in your programming routine and correct all messages (It will display the errors in the form of messages).
  • Always use the Code Inspectortool (transaction SCI) using the standard check variant, and correct all messages.
  • You must check the usability & accessibility of your interface (GUI) elements by using all available appropriate tools (integrated into the workbench tools and ABAP Test Cockpit).
  • You must cover all the functions of your procedural units by using unit tests with ABAP Unit (integrated into ABAP Workbench, Code Inspector, and ABAP Test Cockpit).
  • All the functions of your application must be covered by using scenario tests (e.g. for calculator, the scenario will be two inputs and pressing Add ‘+’ button) with eCATT (transaction SECATT).
  • For better performance of your code, check the memory consumption of your programs, and for that, you can use ABAP Memory Inspector (transaction S_MEMORY_INSPECTOR), and by using the memory analysis function integrated into the ABAP Debugger.
  • Check runtime behaviour and performance by using the ABAP runtime analysis tool (transaction SAT).
  • Check the test coverage by using a coverage analyser (transaction SCOV and integrated into ABAP Unit Browser of ABAP Workbench).
  • You must follow the ABAP – Security Notes(for more, visit: https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/abenabap_security.htm) to protect your programs and data from attacks from outside.
  • A programmer must make his program readable. For that, you need to Document your programs (codes) and services using all available means: Starting with comments, this ranges from simple data element documentation for context-sensitive input help, to class and method documentation for documenting APIs, to explanations of concepts and tutorials in other repositories such as SAP Knowledge Warehouse, or on the Internet, for example in the SAP Developer Community (SCN, http://scn.sap.com).

What I actually wanted to tell you is that whenever you start coding, use the tools underlined above. You might not need them, and you might be a perfect coder, but nobody in the industry will tell you to use ABAP programming guidelines, and your code will fail in the testing phase. So, make it a habit to follow the ABAP programming guidelines.

More ABAP Programming Guidelines

  • Use ABAP objects: Use ABAP objects wherever possible for new and further developments. Here are the reasons why:
    • Data encapsulation: Simple Reports, FM doesn’t give a clear differentiation between externally and internally usable data. But ABAP object does use PUBLIC, PRIVATE and PROTECTED sections.
    • Explicit instantiation: Multiple instantiations and automatic garbage collection (it means auto-deletion of unused memory) have exclusive advantages.
    • Inheritance: Reuse of classes via inheritance reduces code.
    • Interfaces: This means that developers do not need to concern themselves with the implementation details of the class behind the interface.
    • Events: Events define a program flow strictly, and event trigger does not need to know about any other handlers.
    • Cleansed Syntax: Classical ABAP reports have evolved over time and contain several obsolete and overlapping concepts.These obsolete concepts were kept aside during the construction of ABAP object concepts
    • Access to new technology: ABAP objects are often only the way to deal with new technology. Web Dynpro ABAP and ICF (Internet Connection Framework) provides only class-based interfaces. UI5 supports classes and FMs only.

 

  • Original Language: Once specified, there is currently no technical support for the replacement of an original language by another language across an entire project. We specify it every time we create a new object in ABAP repository.
  • Program Type: Select the appropriate program type according to your requirement. Following are the possible program types in ABAP(We will read about them in detail later):
    • Executable program: ABAP Editor creates executable programs. These are simple programs and supports selection screens.
    • Class pool: The Class Buildertool in ABAP Workbench (SE80) can define these. They are used as a repository for global classes and interfaces.
    • Interface pool: These are the ABAP programs that contains the definition of exactly one global interface and it is loaded using the interface.
    • Function group (function pool): All function modules we create belong to a function group. A function group is a collection of function modules sharing global data with each other.
    • Module pool: The ABAP editor (SE38) helps create a module pool. They are a collection of screens and are called via transaction codes.
    • Subroutine pool: ABAP editor (SE38) creates these. They are a collection of subroutines.
    • Type group (Type Pool): ABAP Dictionary (SE11) creates these. They are a group of TYPES and CONSTANTS.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.