Archive for ‘ May, 2013 ’

ABAP Naming Conventions

Call a Spade a Spade

Naming conventions must be concise, short and distinct. Any ambiguity is a burden for maintenance in the future. Using three categories of criteria it is possible to unambigously name virtually all variables and most signature parameters:

  1. Visibility: Global / Local / Class Context
  2. Type: Field / Structure / Table Type / Reference / Constants
  3. Structural Context: FORM routines / Function Modules / Methods

There are two general naming conventions:

  • Variables and Class Attributes: <Visibility>_<Type>_<Description>
  • Signature Parameters: <Structural Context>_<Type>_<Description>

Visibility & Type

We have three kinds of visibility: Global, Local and Class Context (which includes Interfaces as well) and seven different types (see below).

 

Visibility Prefix Type Prefix Example Coding
Global G Field D GD_MATNR DATA: gd_matnr TYPE matnr.
    Structure S GS_KNB1 DATA: gs_knb1 TYPE knb1.
    Table Type T GT_VBAK DATA: gt_vbak TYPE TABLE OF vbak.
    Class

Interface

O GO_GRID

GO_MSGLIST

DATA: go_grid TYPE REF TO cl_gui_alv_grid.

DATA: go_msglist TYPE REF TO if_reca_message_list.

    Data Object DO GDO_DATA DATA: gdo_data TYPE REF TO data.
    Constant C GC_LIGHTSPEED CONSTANTS: gc_lightspeed TYPE i VALUE ’300000′.
Local L Field D LD_MATNR DATA: ld_matnr TYPE matnr.
    Structure S LS_KNB1 DATA: ls_knb1 TYPE knb1.
    Table Type T LT_VBAK DATA: lt_vbak TYPE TABLE OF vbak.
    Class

Interface

O LO_GRID

LO_MSGLIST

DATA: lo_grid TYPE REF TO cl_gui_alv_grid.

DATA: lo_msglist TYPE REF TO if_reca_message_list.

    Data Object DO LDO_DATA DATA: ldo_data TYPE REF TO data.
    Constant C LC_LIGHTSPEED CONSTANTS: lc_lightspeed TYPE i VALUE ’300000′.
Class Context M Field D MD_MATNR DATA: md_matnr TYPE matnr.
    Structure S MS_KNB1 DATA: ms_knb1 TYPE knb1.
    Table Type T MT_VBAK DATA: mt_vbak TYPE TABLE OF vbak.
    Class

Interface

O MO_GRID

MO_MSGLIST

DATA: mo_grid TYPE REF TO cl_gui_alv_grid.

DATA: mo_msglist TYPE REF TO if_reca_message_list.

    Data Object DO MDO_DATA DATA: mdo_data TYPE REF TO data.
    Constant C MC_LIGHTSPEED CONSTANTS: mc_lightspeed TYPE i VALUE ’300000′.

 

The vast majority of variables within program objects are either global or local. And in the future there will be a remarkably shift towards class attributes (ABAP-OO). Thus, assigning a unique prefix to each group makes their visibility unambigous for every developer.

Class attributes (instance and static) are special because they are global within the class/instance whereas they appear local from outside the class/instance. Without referring to a class(name) or instance these attributes are “hidden” (i.e. local).

Question: Does the type prefix offer any benefit?

In ABAP forum posts you may find the following definitions for ALV grid instances:

  • GRID: global (?), local (?), class context (?); class reference (?)
  • G_ALV_GRID: global (!?), local (?), class context (?); class reference (!?)
  • GO_GRID: global class reference OUTSIDE any class context (my naming convention)

Answer: Yes, because we meet the developer’s expectation and anticipation.

You may argue: What a big fuss about such a little subtlety. My answer to this is: Every SAP developer who comes across a GO_GRID variable in any of my programs knows in advance(!) the meaning and scope of it.

Structural Context (1): FORM routine Signature

The SAP system does not care about which kind of formal parameters (USING or CHANGING) are used in FORM routine signatures. Both kinds of formal parameters can be changed within the routine and the modified contents transferred back to the calling program. This is ambiguity at its worst.

In order to make the signature of a FORM routine clear as crystal we define every Input = USING parameter and everyOutput = CHANGING parameter. Within the FORM routine all USING parameters should be regarded as “constants” meaning that they are not changed nor is any change transferred back to the calling program.

 

Parameter Prefix Type Prefix Example
USING U Field D UD_MATNR
Structure S US_KNB1
Table Type T UT_VBAK
ClassInterface O UO_GRIDUO_MSGLIST
Data Object DO UDO_DATA
CHANGING C Field D CD_MATNR
Structure S CS_KNB1
Table Type T CT_VBAK
ClassInterface O CO_GRIDCO_MSGLIST
Data Object DO CDO_DATA

 

Again, by defining Input = USING (prefix ‘U’) and Output = CHANGING (prefix ‘C’) we meet the developer’s expectation and alleviate understanding of the FORM routine.

Structural Context (2): Function Module Signature

The same logic applies to function modules parameters. In addition, we can facilitate the understanding of TABLESparameters (Yes, I know they are obsolete yet some still like to use ‘em) by the semantics of their Input/Output behaviour:

  • IT_ITAB = Input only
  • ET_ITAB = Output only
  • XT_ITAB = Input & Output

 

Parameter Prefix Type Prefix Example
IMPORTING I Field D ID_MATNR
Structure S IS_KNB1
Table Type T IT_VBAK
ClassInterface O IO_GRIDIO_MSGLIST
Data Object DO IDO_DATA
EXPORTING E Field D ED_MATNR
Structure S ES_KNB1
Table Type T ET_VBAK
ClassInterface O EO_GRIDEO_MSGLIST
Data Object DO EDO_DATA
CHANGING C Field D CD_MATNR
Structure S CS_KNB1
Table Type T CT_VBAK
ClassInterface O CO_GRIDCO_MSGLIST
Data Object DO CDO_DATA
TABLES “Importing” IT IT_VBAK
“Exporting” ET ET_VBAK
“Changing” XT XT_VBAK

 

Of course there is no technical difference whatsoever between “Importing”, “Exporting” and “Changing” TABLES parameters. Yet the different naming gives the developer already an idea about the function of this module without looking into the coding. Or in other words: Try to “express” the function of the module already in its signature.

 

 

 

Structural Context (3a): Method Signature

 

The logic explained above is just applied to method parameters as well and extended to the additional RETURNING parameters of methods.

Parameter Prefix Type Prefix Example
IMPORTING I Field D ID_MATNR
Structure S IS_KNB1
Table Type T IT_VBAK
ClassInterface O IO_GRIDIO_MSGLIST
Data Object DO IDO_DATA
EXPORTING E Field D ED_MATNR
Structure S ES_KNB1
Table Type T ET_VBAK
ClassInterface O EO_GRIDEO_MSGLIST
Data Object DO EDO_DATA
CHANGING C Field D CD_MATNR
Structure S CS_KNB1
Table Type T CT_VBAK
ClassInterface O CO_GRIDCO_MSGLIST
Data Object DO CDO_DATA
RETURNING R Field D RD_MATNR
Structure S RS_KNB1
Table Type T RT_VBAK
ClassInterface O RO_GRIDRO_MSGLIST
Data Object DO RDO_DATA

 

 

Structural Context (3b): Static vs. Instance Attributes

Static attributes are special because they exist only once for all instances of this class. Modifying a static attribute within a given instance makes this change visible to all other instances. Both types of attributes have the prefix ‘M’ (class context) in my naming convention. In order to distinguish between static and instance attributes I apply the following convention:

  • Instance Attribute: with self-reference me-> (e.g. me->md_key)
  • Static Attribute: without self-reference (.e.g. ms_row)

You can find an example of this naming convention in the coding of INCLUDE ZRSWBOSDR_C01 in my blog Multi-Purpose ALV Programming.

Another unambigous convention is to drop the self-reference prefix and use the full qualified name for static attributes:

  • Instance Attribute: md_key (with or with self-reference prefix)
  • Static Attribute: lcl_eventhandler=>ms_row

Field-Symbols

We can apply the same naming conventions even to field-symbols which makes them much more readable and understandable for every developer. This is particularly important because the contents of field-symbols cannot be analyzed statically but is only determined at runtime.

Visibility Prefix Type Prefix Example
Global G Field D <GD_MATNR>
Structure S <GS_KNB1>
Table Type T <GT_VBAK>
ClassInterface O <GO_GRID><GO_MSGLIST>
Data Object DO <GDO_DATA>
Local L Field D <LD_MATNR>
Structure S <LS_KNB1>
Table Type T <LT_VBAK>
ClassInterface O <LO_GRID><LO_MSGLIST>
Data Object DO <LDO_DATA>

SAP and Lego

Why has Lego become one of the world’s most famous toys? Part of the answer can be found here:

“Lego pieces of all varieties are a part of a universal system. \ Despite variation in the design and purpose of individual pieces over \ the years, each remains compatible in some way with existing pieces. \ Lego bricks from 1958 still interlock with those made in 2009, and Lego \ sets for young children are compatible with those made for teenagers.

\ Bricks, beams, axles, mini figures, and all other parts in the Lego \ system are manufactured to an exacting degree of precision. When \ snapped together, pieces must have just the right amount of strength \ and flexibility mixed together to stick together. They must stay \ together until pulled apart. They cannot be too easy to pull apart, or \ the resulting constructions would be unstable; they also cannot be too \ difficult to pull apart, since the disassembly of one creation in order \ to build another is part of the Lego appeal. In order for pieces to \ have just the right “clutch power”, Lego elements are manufactured \ within a tolerance of 2 µm.”

QUESTION: ”Have you ever seen a child which sits in front of a pile of Lego bricks claiming it can’t build anything because all bricks have the same size???”

For me SAP is just an incredibly huge pile of Lego bricks (for grown-ups). Consistent naming conventions are an indispensable standard which enables us to manufacture long-lasting developments that are easy to understand and maintain (pull apart and reassemble).

 

source:  <http://scn.sap.com/people/uwe.schieferstein/blog/2009/08/31/nomen-est-omen–abap-naming-conventions>

INFORMATION