SAP ABAP Development Style Guidelines

ABAP Objects Style Guidelines

These are intended to be guidelines and instructions on the use of SAP ABAP for programming in a business scenario. Style guidelines, as opposed to standards, are intended to guide the programmer, not dictate the only way to utilize a programming language. There may be cases where development professionals will need to deviate from these guidelines and that decision is left up to the developer.

 

Guide use

Advanced Solutions uses this style guide to guide our development, ABAP more then any other language has a readability that makes it approachable by analysts and/or power users. By improving our style and manner in which we use the language we hope to make it easier for not only our own development teams but also future developers tasked with updating our code and hopefully making it easier for analysts to inspect our code and validate or understand the methods we use to solve a particular problem. For Non Advanced Solutions customers we hope that you find the style guide useful and always happy to get feedback from the community to increase the scope of our style guide or improve it. Style guides are tricky, developers are opinionated creative professionals so approach it as we have as an reference as to how others might approach the styling of a particular object. Enjoy!

General Naming Convention

The following naming conversion applies throughout the guidelines and should be a general rule for naming any object unless otherwise specified.

  • Create names that are pronounceable.  If you cannot read the name out loud to someone, it’s not a good one. GLacct would not be pronounceable whereas glAccount would be better. Acronyms should be avoided unless their meaning is widely understood. (A good way to consider naming is that we are writing for someone other then ourselves to review.)
  • Use capitalization or underscore for new words.  In the example above, we use glAccount.  The capital letter makes it clear to the reader that these are separate words and makes it more readable than glaccount.  The other alternative would be gl_account. Note: the ABAP class builder forces all attributes to uppercase so it make sense to use “_” instead of capitalization to separate words, at least when using the ABAP language.
  • Avoid digits where possible. We don’t want someone misinterpreting 0 (zero) for O.

SAP ABAP Guidelines and Standards

Packages

(Called development classes in pre-4.6 versions.)

General Rules

Packages are the successors to development classes in older versions. They are closer to alignment with UML packages. Packages are containers used to collect all development types and classify them by their purpose. Packages should describe the functions within a project.  There are some restrictions imposed by SAP itself, as follows:
  • SAP standard objects use package names starting with A-S or U-X. Customer objects cannot be added to these packages.
  • Custom-developed, permanent objects use package names starting with Y or Z.
  • Like other repository objects, packages can belong to a prefix namespace if the relevant namespace is installed in your R/3 system. Packages begin with a namespace prefix enclosed in slashes (/). In a package of this type, you can only create object that belong to the same prefix namespace.
  • Package names can be up to 30 characters long.
Note: packages can be nested, thus allowing a fair amount of classification.

Suggested Naming Standard

 

Package Name  

<Prefix><Application Area><Separator><Description>

 

 

Glossary

 

Prefix Z, Y or namespace

Normal customer-developed objects should be prefixed with Z. Y should only be used when a object is local and will not be transported. When a namespace is involved, that would be used as a prefix, i.e. “/Prefix/FIDEV”.

Application Area FI, PP.MM, etc.

Functional Application Area. Note: it is typical to use SAP’s Application Areas but others work as well.

Separator  “_” use an underscore
Description Description of package data / Project

Examples

A custom package for development of a finance initiative:
ZFI_ARIMP
A package being used for local development that will not be transported: (Note: we do not recommend the use of the Y prefix. Rarely is there a need for a local object.)
YFI_ARIMP
A package being developed in a custom namespace for the Acme company:
/ACME/FI_ARIMP
Note: when using a custom namespace, the Z or Y prefix is no longer needed.

ABAP Programs - Non OOP

General Rules

Processing blocks are important to identify so as programs are modified, the processing blocks can be taken into context.

#”’AT-SELECTION-SCREEN”’
#”’START-OF-SELECTION”’
#”’END-OF-SELECTION”’
#”’AT LINE-SELECTION”’

The leading practice is to specifically identify these blocks within code for easier maintenance, readability and troubleshooting.

*————————————————————————
LOAD-OF-PROGRAM. “Called Once when program is loaded
*————————————————————————

Comments should support the ABAP coding.

Typically, comments can be extracted from functional spec documentation. They also provide the analyst reviewing the code a chance to see the functions supporting the spec.

Care should be taken to ensure that comments are not excessive. Thus, a comment should not be longer then the code it explains.

= Transaction Codes =
Transaction codes in SAP are used to access a transaction quickly. Typically, transaction codes are shorter then the program they are calling, though this is not a rule. Transaction codes also provide a method to verify user authorization for a specific application.

For OO purposes, the transaction code initiates the call to the MAIN class and method.

Transaction codes should follow a similar guideline as programs.

Suggested Naming Standard

ABAP Programs

 

Glossary

 

Example

I am writing a report to review material ATP. Though the program maybe named ZSD_MaterialATP, I use the guidelines above to use a transaction code of ZSDMATATP, which is easier to type in the command box.

Global Classes

Naming conventions for custom classes.

General Rules

 

Suggested Naming Standard

Class Name <Prefix><Class Prefix><Separator><Class Name>

 

Glossary

Prefix Z, Y or namespace. Normal customer-developed objects should be prefixed with Z. Y should only be used when an object is local and will not be transported. When a namespace is involved, that would be used as a prefix, i.e. “/Prefix/FIDEV”.
Class Prefix FI, PP.MM, etc.

Functional Application Area. Note: it is typical to use SAP’s Application Areas but others work as well.

Separator  “_” use an underscore
Class Name Use proper nouns such as COMPANY_CODE GENERAL LEDGER_ACCOUNT, etc.

 

Examples

A class should be named after the object it represents. For example, a master data class to maintain a vendor using the naming convention above could be ZCL_Vendor. A class to define a customer could be ZCL_CUSTOMER. There can any type of variations.

 

 

 

Persistent Classes

General Rules

Suggested Naming Standard

Persistent classes utilize the persistent services and provide an abstraction layer of the database tables.  Because they differ from standard classes, a leading practice is to identify them differently, so we recommend a separate naming guideline.

 

Glossary

 

Examples

A class that manages the persistence to a table called ZTAB would be named ZCL_PERS_ZTAB.

Class Attributes

General Rules

A class attribute similar to a variable in a regular program is a reference to a memory location where you can store data. An attribute of a class when instantiated is a block of memory reserved for an instance.

 

Suggested Naming Standard

Since they are isolated to the instance, attributes provide a little more flexibility in naming, and so naming should be descriptive of the attribute.  An attribute should use the following naming convention.

Attribute Name <Descriptive name>

 

Glossary

<Descriptive Name> Descriptive attribute name that identifies the value being captured, note Pascal case. When using multiple works, the first letter is capitalized.

 

Examples

An attribute for a country code could be CountryCode.
An attribute for a bool type identifying whether a document has been printed could be HasPrinted.
An attribute for a general ledger account could be generalLedgerAccount. Note: we do not use the acronym GLaccount (though we could), because it is less descriptive and the full name is very clear.
Remember that the length of the name has no impact on performance. It is only important for code clarity, so use as many characters as you need for clarity.

Note about self reference when referencing attributes within a method of a class. The use of me-> to reference the attributes is not required by ABAP itself but is, as a rule, a best practice to emphasize the distinction between local variables and class attributes that may be already available.

Object-Oriented Class Development

Global Classes

Naming conventions for custom classes.

General Rules

 

Suggested Naming Standard

Class Name <Prefix><Class Prefix><Separator><Class Name>

 

Glossary

Prefix Z, Y or namespace. Normal customer-developed objects should be prefixed with Z. Y should only be used when an object is local and will not be transported. When a namespace is involved, that would be used as a prefix, i.e. “/Prefix/FIDEV”.
Class Prefix FI, PP.MM, etc.

Functional Application Area. Note: it is typical to use SAP’s Application Areas but others work as well.

Separator  “_” use an underscore
Class Name Use proper nouns such as COMPANY_CODE GENERAL LEDGER_ACCOUNT, etc.

 

Examples

A class should be named after the object it represents. For example, a master data class to maintain a vendor using the naming convention above could be ZCL_Vendor. A class to define a customer could be ZCL_CUSTOMER. There can any type of variations.

Methods

General Rules

 

Suggested Naming Standard

Method Name

 

Glossary

Method Name Method name. Use clear verbs to describe what the method does, i.e. PRINT.

 

Examples

Method Parameters

General Rules

 

Suggested Naming Standard

Method Parameter <Type>_<Parameter description>

 

Glossary

Method Name Type of parameter. E = Exporting , I = Importing, etc.
<Parameter Description> Descriptive name for the parameter being passed.

 

Examples

A general ledger account class has server parameters identified for the constructor method. They are:

I_generalLedgerAccount
I_companyCode

Class Attributes

General Rules

A class attribute similar to a variable in a regular program is a reference to a memory location where you can store data. An attribute of a class when instantiated is a block of memory reserved for an instance.

 

Suggested Naming Standard

Since they are isolated to the instance, attributes provide a little more flexibility in naming, and so naming should be descriptive of the attribute.  An attribute should use the following naming convention.

Attribute Name <Descriptive name>

 

Glossary

<Descriptive Name> Descriptive attribute name that identifies the value being captured, note Pascal case. When using multiple works, the first letter is capitalized.

 

Examples

An attribute for a country code could be CountryCode.
An attribute for a bool type identifying whether a document has been printed could be HasPrinted.
An attribute for a general ledger account could be generalLedgerAccount. Note: we do not use the acronym GLaccount (though we could), because it is less descriptive and the full name is very clear.
Remember that the length of the name has no impact on performance. It is only important for code clarity, so use as many characters as you need for clarity.

Note about self reference when referencing attributes within a method of a class. The use of me-> to reference the attributes is not required by ABAP itself but is, as a rule, a best practice to emphasize the distinction between local variables and class attributes that may be already available.

Persistent Classes

General Rules

Suggested Naming Standard

Persistent classes utilize the persistent services and provide an abstraction layer of the database tables.  Because they differ from standard classes, a leading practice is to identify them differently, so we recommend a separate naming guideline.

 

Glossary

 

Examples

A class that manages the persistence to a table called ZTAB would be named ZCL_PERS_ZTAB.

 

Error Classes

General Rules

Error classes are classes specifically designed to trap errors from a class.

Suggested Naming Standard

Prefix ZCX_object name

Glossary

 

Examples

Preferably, the object name is the same as the class object name that it is linked to, so furthering out the example, the ZCL_generalLedgerAccount class has an Error Class called ZCX_generalLedgerAccount.

= Variable Naming =

Global vs. Local Objects
In ABAP objects, it is possible to isolate variables within the class instance. In standard procedural code, it is up to the developer to ensure they limit the variables available to only the modules that need access to it. Thus, all variables should be local to a module unless the variable will be used across modules.

Ready To Get Started?

error: Content is protected !!

Pin It on Pinterest