[ABAP Part TWO] Program Development Phase 2 - Your Coding Style Define The Quality

Now we step into Naming Conventions for each of obj in the program, you can understand it as a prefix string for diff type of obj.

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