Official ABAP Programming Guidelines [As per SAP Documentation]:

ABAP Programming Guidelines as per the official SAP Documentation consists of 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
  • easier to reuse
  • easier to transport
  • easier to maintain
  • easier to test

It can be as simple as keeping data declarations and the implementation of the functions separate to keeping different segment 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:

  • Include the extended program check(transaction code is SLIN) in your programming routine and correct all messages (It will display the errors in 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’s tests with ABAP Unit (integrated into ABAP Workbench, Code Inspector, and ABAP Test Cockpit).
  • You must cover all the functions of your application by using scenario tests (e.g. for calculator, 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) & 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 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 testing phase. So, make it an habit to follow the 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 using PUBLIC, PRIVATE and PROTECTED sections.
    • Explicit instantiation: Multiple Instantiation and Automatic garbage collection (it means auto deletion of unused memory) has its 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 overtime and contain several obsolete and overlapping concepts while during construction of ABAP object concepts, these obsolete concepts were kept aside.
    • 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, also 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 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: Executable programs are created in ABAP Editor. These are simple programs and supports Selection Screens.
    • Class pool: These can be defined using Class Buildertool in ABAP Workbench (SE80) and are used as a repository for global classes and interfaces.
    • Interface pool: These are the ABAP programs which contains the definition of exactly one global interfaceand it is loaded using the interface.
    • Function group (function pool): All function modules we create belong to a Function Group and Function Group is a collection of function modules sharing global data with each other.
    • Module pool: Module Pool is created with the help of ABAP editor (SE38). They are collection of screens and called via Transaction codes.
    • Subroutine pool: These are created with the help of ABAP editor (SE38). They are collection of subroutines.
    • Type group (Type Pool): These are created with the help of ABAP Dictionary (SE11). They are group of TYPES and CONSTANTS.

Leave a comment

Your email address will not be published. Required fields are marked *

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

Translate »