Naming Conventions
Naming Conventions lend consistency and readabilty to your code. This in turn improves the overall maintainability of code. When naming your objects and variables, try to avoid arcane acronyms. Spell it out where possible.
Refer to the table below for accepted industry standard naming conventions for objects and variables within a program.
| Program Internal Objects | Convention | Example |
| Class - local | lcl_* | lcl_salesorder |
| Class - Interface | lif_* | lif_salesorder |
| Constant | c_* or co_* | c_open_indicator |
| Data Reference | dr_* | dr_openorder |
| Data Variables - Global | v_* or gv_* | v_order |
| Data Variables - Local | lv_* | lv_order |
| Data Variables - Static | lsv_* | lsv_order |
| Field Symbols | <fs_*> | <fs_order> |
| Internal Table - Standard | t_* | t_orders |
| Internal Table - Sorted | ts_* or to_* | ts_orders |
| Internal Table - Hashed | th_* | th_orders |
| Parameters | pa_* | pa_order |
| Ranges | ra_* | ra_orders |
| Reference Variable | rf_* | rf_orders |
| Select-Options | so_* | so_date |
| Structure | st_* or w_* | st_orders |
| Table Control | tc_* | tc_orderlines |
| Types | ty_* | ty_ordertype |
| Work Area | w_* | w_order |
Interface Parameters
| Subroutine Formal Parameters | Convention | Example |
| Using | u_* or p_* | |
| Changing | c_* or p_* | |
| Raising | r_* or p_* | |
| Method Signature | Convention | Example |
| Importing | im_* | |
| Exporting | ex_* | |
| Changing | ch_* | |
| Returning | re_* | |
| Raising | cx_* for exception classes | |
| Exceptions | not applicable | |
| Function Interface | Convention | Example |
| Importing | im_* | |
| Exporting | ex_* | |
| Changing | ch_* | |
| Tables | t_* | |
| Exceptions | not applicable | |
| Raising | not applicable |
Program Title
The title as defined in the attributes of the program should contain a description that includes the program type and the functionality it performs. For example:
· Data Load - Materials for Plants
· Inbound Interface - Receive Supplier Orders
· Report – Cost Centre Sales Breakdown
Program Description
High level descriptions of the program are to be kept as comments at the beginning of the program or in the documentation section of a program using the ‘Documentation’ tag label. A URL link can be provided that points to the Technical specifications, diagrams layouts, data mapping, etc. For Module Pools, the program documentation should be placed in the TOP include.From my point of view , I think everyone should follow this rule .This is a good habit.
The Maintenance History section is to be used to document program changes as well as the initial creation of the program. Keep this documentation concise and brief. Detailed documentation should be kept in the technical spec and should be easily accessed. Version Management is used to verify releases of the code. If the change request and date are maintained in the code, then version management can be used to validate the code that changed for a given change request.
Below are a couple of examples.
Simple Example
More Detailed Example
Subroutines
All FORMS should be self-explanatory. Use the full 30 characters to describe the form if necessary. Avoid abbreviations in the name unless you are limited for space i.e. instead of calc_avg_prc use calculate_average_price.
When using forward navigation to create a subroutine, the system generates a proposed format for the comment section and the FORM and ENDFORM statement. It is suggested that you stick to this generated format with minimal alteration. The generated comment box should always precede the subroutine and maintained with a short description of the intent of the routine. DO NOT attempt to describe the logic of what is taking place.
The naming convention for formal parameters varies across SAP customer sites. Although the workbench generates a proposed name for you by prefixing the variable name with “P_” , this is not commonly practiced. i.e. actual parm being passed to the form is T_MESSAGE_ID then the name of the formal parameter would be named PT_MESSAGE_ID. The workbench generates directional arrows automatically based on the parameter usage i.e. using, changing, using (value).
Example:
Functions/Methods
FUNCTIONS
Use the built in documentation features found in SE37 to document the purpose of the function modules and the usage of the Interface parameters.
The use of naming standards for interface parameters is not a common practice, although it should be so SAPdomain recommends the following:
Importing Parameters: IM_*
Exporting Parameters: EX_*
Changing Parameters: CH_*
Tables Parameters: TB_*
METHODS
For Methods Use the Following naming standard for the signature of the method.
Importing: IM_*
Exporting: EX_*
Changing : CH_*
Returning: RE_*
Raising: exception (no std)
Exceptions: exception_class (no std)
Modularization
Blocks of code that are executed more than once within one program must be placed in a callable processing unit. This could be a FORM, Method, or Function.
Subroutines are used as self-contained sections of code that perform a well defined function. They are used to organize code flow and readability.
A Subroutine should only perform one primary process. If it is performing more than one process, then it should be divided into multiple subroutines.
Subroutines that are used by more than one program should be placed in a Function Module or ABAP OO Method.
PERFORM is recommended rather than inline coding for all list processing events such as Start-of-Selection, At Selection-Screen, AT User-Command, etc.
List Processing Events Example
.... To Be Continued