SAP@RRAB

Programming Standards and Guidelines

ACC-ABAP Programming Standards and Guidelines-20100119

V1.0

Project SAP@RRAB
Document ID ACC-ABAP Programming Standards and Guidelines-20100119 V1.0

Author / Reviewer Version Date Distribution List

Thangeswaran T.K Version 1.0 19-Jan-10

Version History
Ver. Ver. Date Changed Change Description Filename
No. By
1.0 19-Jan-10 Initial Draft ACC-ABAP Programming Standards
and Guidelines-20100119 V1.0
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January 2010 2/1/2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0
UPDATED : 1 February 2010
20100119

Table of Contents

1 General Programming Standards................................................................................. 3

2 Coding ABAP Programs .............................................................................................. 4
2.1 Program Attributes Screen ....................................................................................... 4
2.2 Transport Attributes .................................................................................................. 6
2.3 Program Heading ..................................................................................................... 6
2.4 Maintenance of ABAP code ...................................................................................... 7
2.5 Data Declarations ..................................................................................................... 7
2.6 Forms ....................................................................................................................... 8
2.7 Includes .................................................................................................................... 8
2.8 Internal Data Names ................................................................................................ 9
2.9 Global Variables ....................................................................................................... 9
2.10 Parameters ......................................................................................................... 10
2.11 Selection Option ................................................................................................. 10
2.12 Ranges ............................................................................................................... 10
2.13 Internal Tables .................................................................................................... 10
2.14 Field Structure .................................................................................................... 11
2.15 Types .................................................................................................................. 11
2.16 Local Variables ................................................................................................... 11
2.17 Coding Comments .............................................................................................. 11
2.18 Documentation /Text Elements ........................................................................... 13
2.19 Custom Report Layouts ...................................................................................... 14
3 Online Programming .................................................................................................. 15
3.1 Overview ................................................................................................................ 15
3.2 General Guidelines ................................................................................................. 16
4 Enhancements / User-Exit ......................................................................................... 16
5 SAP Script / Smartform Programming ........................................................................ 18
6 Function Modules ...................................................................................................... 19
7 Recommended Programming Techniques and Constructs ........................................ 19
7.1 Database Operation ............................................................................................... 19
7.2 Control Events ........................................................................................................ 21
7.3 Internal Tables........................................................................................................ 21
7.4 General Constructs / Techniques ........................................................................... 22
8 Appendix 1 ................................................................................................................. 24
9 Appendix 2 ................................................................................................................. 24
10 Appendix 3 ................................................................................................................. 25
11 Appendix 4 ................................................................................................................. 26
12 Appendix 5 ................................................................................................................. 31
13 Appendix 6 ................................................................................................................. 32

2
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

1 General Programming Standards

The general ABAP programming standards are as follows:

 All ABAP/4 dictionary objects created must follow the standards set forth in Appendix 3 -
Naming Standards.

 Codes re-use: Before creating a new SAP object, check to ensure that there is not an
existing object that can perform the same task. If one exists, use that one instead of
creating a new one.

 Anytime you create a function module that performs a common operation, contact the rest
of the team so that they can use the function module that you‟ve written if necessary.

 Attributes for each new ABAP must be set in accordance with the values given in the
Program Attributes section of this document.

 Never hard-code values in your programs. If literal values for logical expressions are
required, then declare parameters or working storage constants in the data declaration
section of your program. In this manner, the literal can be easily maintained going forward.

 Code one ABAP statement per line. This allows for easier deleting, commenting, and
debugging.

 Separate different logical parts of source code with blank lines when applicable. This helps
others view the overall program flow.

 Use comments to explain the purpose and/or characteristics of the program subdivisions
and major components. The comments must be meaningful for each construct in isolation
and explain the function of the construct within the entire program. If we don‟t do this, the
code won‟t be maintainable. For further information, refer to the Coding Comments section
of this document.

 Use local variables within a form but they must use the naming standards described in the
Internal Data Names section of this document.

 Each program should contain a documentation header box at the start of each program.
This should include: Program name, description, author, date of creation, tables, files,
logical data bases and description of each change including the author and date changed.
When creating a program you can copy an existing ABAP template into your own code.
Select the option Insert Statement in the Edit menu option or press CTRL + E. Then, click
on Other Patterns and choose Z_PROGRAM_HEADER. Please refer to Appendix 1 for
details on the Header template.

 Programs should indent via pretty printer command and be modularized to ensure clarity.

 After every database call, file opening, reading and closing the system variable SY-SUBRC
must be checked.
3
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

 Interface programs should be designed so that runtime failures will allow a restart/recovery
that does not result in data loss or corruption. It is desirable to archive the input file for
some time period to allow re-run if necessary. Production interfaces should limit the size of
the BDC batches to prevent deteriorating response time for on-line users.

 Audit trail logs should be created to provide information on errors and functional activities.

 Define all types together, e.g., all data variables declarations should be grouped together,
all parameters together, etc.

 Utilize LIKE whenever possible for definition of program variables.

 Use underscores (_) rather than dashes (-) in variable names.

 Year 2000 compliance – All programs must be able to accommodate the millennium
rollover. There should be no hard coded date manipulation in any program that is moved to
the production environment. When creating date variable in the program always reference
to the date system variable (SY-DATUM) or to a DDIC date table field.

 Whenever possible use logical file names when reading or writing to a non-SAP file. When
developing interfaces, it is advisable to create new logical file names that conform to the
COMPANY standard.

 Be aware that the “WS_” function modules (e.g. WS_UPLOAD) cannot run in background.

 For control purposes, the AUTHORITY-CHECK statement must be used to check user‟s
authorization on the object.

 When processing long sessions notifying the Basis team to arrange suitable time.

2 Coding ABAP Programs

2.1 Program Attributes Screen

While creating an ABAP, the system displays the Program Attributes screen. When creating the
ABAP program, please refer to this section so that the fields can be properly populated on the
Program Attributes screen.

Title The title should be a short, concise description of the ABAP. This is the title
that appears in the header of a report when you execute it (unless you
override this feature via Text Elements or the NO STANDARD-PAGE
HEADING command).

Type
„1‟ for online programs running online or in batch
„I‟ for include programs
4
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

„M‟ for module pools

„F‟ for function programs
„S‟ for external subroutine programs

Status
„T‟ for test programs
„K‟ for self-developed production programs
„P‟ for SAP standard production programs (not used for new development)
„S‟ for System programs (not used for new development)

Application
SAP Application. Look up at the options via key „PF4‟. This field has to be
consistent to SAP Module used to build up the program name (please refer
to the Appendix 3 - Naming Standards).

Logical Database
Assign the logical database, if necessary. Press PF18 to help choose the
appropriate database.

From Application
To be used in conjunction with the logical database field. The tables
retrieved to access the particular logical database depend on this entry.

Selection Screen If there are more than one selection screen to choose from, you can specify
one here.

Authorization Group Used to restrict access to users without a matching authorization group in
their profile.

Start via Variant

If the option is checked, the program can only be executed via a variant.

Editor Lock Active

Set this while you are creating or modifying a program. It only allows the
user who set the flag to modify the program. This prevents multiple
modifications to a program at one time.
Warning: Setting this switch is not recommended, as different times in the
development process (i.e. unit testing, system testing, production, etc.); a
Correction / Transport numbering system should be utilized by the developer
team.

Fixed Point Arithmetic

If flagged, all calculations in the program are done using fixed-point
arithmetic.
All programs that contain calculations must have this flag checked. If this
field isn‟t checked, the system only considers decimal places for output, not
for calculations.

5
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

2.2 Transport Attributes

After completing the Program Attributes screen of your newly created program, save the attributes.
The system displays the „Maintain Transport Attributes‟ pop-up window. If you‟re simply writing a
test program that you don‟t want to transport, click the „Local Private Object‟ button. If you are
creating a program that will transport, assign it to a development class, save the program, and
create a correction with a description of the object (i.e., the ABAP) attached to the correction.

Note: Before creating programs and assigning them to requests, read the Appendix 6 CTS
Procedures on the BSIP Change Request Management and Transport Procedure (Documentum 
Basis & Infrastructure  Guides  System Policy Guide (SPG)  Change Request Management
and Transport Procedure).

2.3 Program Heading

Your program heading will look like this:

These are the fields which have to be maintained in the heading:

Program name: The 8-character name of the program.

Create Date: The date the program was created.

Author‟s Name: The developer coding the program.

Last Update: The last time the program was updated.

Program Title: The program title. This field should correspond with the program description
field on the Program Attributes screen.

Development
Request #: The development request number assigned by the Status Tracking Tool (STT)
system. This is the link between the ABAP program and the development
request.

Description: A brief description of the functionality of the program.

Includes:
Key in any include that will be used in the program.

Calls:
Here, type any function modules or subroutines (internal or external) that you‟ll
be using in your program.

Change History:
Request #: When making modifications to a program that has been completed, include a
request number here.

Date: The date the program was modified.

6
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

Developer: The name of the person who modified the program.

Description: A short description of the modification to the program.

Please refer to Appendix 1 for details on the program heading.

2.4 Maintenance of ABAP code

Any change in a productive program should be documented. Never delete lines. Instead, comment
them out and write the request number on the same line. This is also valid when you are adding
new lines to the code. Do not forget to document your changes in the program header. In this
manner, your modifications will be easy to track. Here‟s an example on how you should do it:

CALL FUNCTION 'SD_VBAK_SELECT'

EXPORTING
I_DOCUMENT_NUMBER = US_VBELN
IMPORTING
E_VBAK = VBAK
EXCEPTIONS “BCTK901234
DOCUMENT_NOT_FOUND = 01. “BCTK901234

* IF SY-SUBRC > 0. “D10K901234

PERFORM BELEG_ENTSPERREN USING US_VBELN.
MESSAGE E302 WITH US_VBELN
* ENDIF. “D10K901234

YVBAK = VBAK.

2.5 Data Declarations

Your data declarations should have the following structure:

REPORT
*PROGRAM HEADING
TABLES
DATA
LITERAL
FIELDS
COUNTERS
FLAGS/SWITCHES
INTERNAL TABLES
FIELD-GROUPS
RANGES
SELECTION-OPTIONS
PARAMETERS

7
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

Use comment boxes to separate the different types of declarations:

Example:
*-------------------------------------------------------
* INTERNAL TABLES
*-------------------------------------------------------
DATA: WC_COUNTER TYPE I.
...
*-------------------------------------------------------
* SELECTION-OPTIONS
*-------------------------------------------------------
SELECT-OPTIONS: MATNR FOR MARA-MATNR.
...

2.6 Forms
FORMs are subroutines that allow a developer to define a process once in a program and call that
routine from different places within the program or, in certain cases, from other programs. Use
FORMs to modularize your program to facilitate maintainability. Each FORM should perform only
one operation. Also, don‟t use a FORM whose only function is to call another FORM.
When creating a form utilize functionality supported by the ABAP Development Workbench by
forward navigation. Double-click on the name of the subroutine in the PERFORM statement.

The following heading will appear at the beginning of every FORM.

*&-----------------------------------------------------*
*& Form F_<name>
*&-----------------------------------------------------*
* F_<name>
*------------------------------------------------------*
* --> p1 F_<name>
* <-- p2 F_<name>
*------------------------------------------------------*

The above fields should contain the following information:

F_<name>: The name of the FORM. The name should be descriptive. For example, if the
FORM reads table LFA1, the name of the FORM should be
F_READ_TABLE_LFA1.
Description: A brief description of the FORM‟s operations.

2.7 Includes
Use Includes for modularizing large report programs or to create report sections that can be
shared by several report programs. Adhere to the naming conventions for ABAPs when creating
includes (Appendix 3-Naming Standards). When you declare the Include in your program,
comment it like this:

INCLUDE ZXXXXXXX. “Function and content of include.

8
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

2.8 Internal Data Names

The following standards pertain to the naming of internal data fields used within ABAP programs.
They are discussed here instead of Appendix 3-Naming Standards because they are ABAP
specific. SAP limits an internal data name to 30 characters. When completing the data declaration
section of your program, refer to these standards.

2.9 Global Variables

Never use variable names containing a dash (“-”). They can be confused with table fields. Use
underscores to separate words in variable/constant names. When naming counters, fields, flags,
or literal/constants, refer to the following matrix so that your program is easy to follow and maintain:

POSITION DESCRIPTION VALUES MEANINGS

1 Working W Working storage
storage
identifier
2 Data type C Counter
F Field
G Flag
L Literal/Constants
W Workflow, Task and Method
container variable
3 Delimiter “_” Underscore; separation
character
4-30 Description A meaningful description of
the variable‟s use/contents.

Examples: Field: WF_TOTAL_VALUE (5) TYPE N,

Counter: WC_TAB_LOOP LIKE SY-INDEX,
Flag: WG_TRUE TYPE C,
Literal: WL_OK_CITY (3) VALUE „OKC‟.
Workflow/Task/Method container: WW_APPROVE_STAT TYPE CHAR5.

9
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

2.10 Parameters
When declaring parameters, make the prefix as “PA_” The rest of the parameter name is a short
description of the parameter‟s use and/or contents. Beware that parameter names can be up to 8
characters long. Also, create a meaningful label for the parameters in the Text Elements section in
your program. Declare parameters like this:

PARAMETERS: PA_O_FILE (40) DEFAULT

„/users/output/prism.dat‟ LOWER CASE

2.11 Selection Option

While declaring select-options, make the prefix as “SO_”. Beware that selection option names can
be up to 8 characters long. Also, create a meaningful label for the selection option in the Text
Elements section in your program. Declare your select-options like this:

SELECT-OPTIONS: SO_CUSTNO FOR KNA1-KUNNR,

SO_VENDOR FOR LFA1-LIFNR

2.12 Ranges
While declaring Ranges, make the prefix as “RA_”. Declare your ranges like this:

RANGES: RA_ACCTNO FOR LFA1-KTOKK,

RA_AUTH FOR LFC1-BEGRU

Note: You can also declare a range like this:

DATA: BEGIN OF INT_RANGE OCCURS 10,

SIGN (1),
OPTION (2),
LOW LIKE f,
HIGH LIKE f,
END OF INT_RANGE

2.13 Internal Tables

While declaring internal tables, make the prefix as “IT_.” This standard ensures that a developer
modifying your code in the future won‟t mistake your internal table for an ABAP/4 dictionary table.
Also, if you‟re declaring an internal table with the structure of an existing database table, give it the
same name as the table (e.g., IT_MARA).

If you know exactly the number of entries your internal table will contain use OCCURS n (where n
is the number of records). It does not make sense to specify n if you do not know the exact
number. In this case leave it to the system the task of allocating memory blocks by specifying
OCCURS 0 (zero). This procedure will avoid excessive memory requirement helping the overall
performance of the program specially when handling large number of internal table‟s entries.

10
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

2.14 Field Structure

Field structures are simply internal tables without OCCURS clauses. While declaring field
structures, make the prefix as “FS_.” Declare field strings like this:

DATA: BEGIN OF FS_MATNR_KEY,

MATNR LIKE MARA-MATNR,
WERKS LIKE T001W-WERKS,
LGORT LIKE T001L-LGORT,
END OF FS_MATNR_KEY

2.15 Types
While declaring Types, make the first 3 characters “TY_.” Declare types like this:

TYPES: TY_NAME (30) TYPE C

DATA: WF_NAME TYPE TY_NAME.

There is really no field-group standards except for the global variable standards mentioned above.
You must also use HEADER and DETAIL to sort. Here‟s an example of field-group usage:

FIELD-GROUPS: HEADER, DETAIL.

INSERT LFA1-NAME1
LFA1-ORT01 INTO HEADER
INSERT IT_ADDRESS-ZIPCODE
IT_ADDRESS-PHONE INTO DETAIL

2.16 Local Variables

Use local variables when you need to pass different parameters to the same subroutine. However,
make the first 4 characters of your local variable “L_” to make it easier for other programmers to
differentiate between global and local variables in your program. Here‟s an example:

FORM F005_ADD_TOTALS USING L_TOTAL.

2.17 Coding Comments

Besides the actual code, the most important thing about your program is the documentation. It is
imperative that you aggressively comment all major constructs in your program so that developers
modifying your code in the future can quickly ascertain your program‟s functionality and flow.
Whenever you develop a program, comment the major constructs as you code them. This way,
you won‟t have to spend a lot of time commenting after the program is complete. Follow these
standards:

 Make your comments concise, complete, and up to date.

 Comment data and variables individually by line using the in-line comment indication (“).
Here‟s an example:

11
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

DATA:
WG_WRITE_FILE (1) TYPE C, “„Write file‟ flag
WC_LOOP_CNTR LIKE SY-INDEX, “Step loop counter
WL_NAME (5) TYPE C VALUE „Vista‟ “company name

 Do not insert full comment lines in the middle of control events (e.g. IF, CASE) to maintain
program readability. Instead, in-line comment should be used.

 In the “Event Processing” section of your code, separate your comments from the code so
that they can be read easily. Refer to the following example:

*--The following code retrieves the currency code------*

 When making comment lines and boxes (and if you‟re using the Command Editor Mode),
use the ABAP command line command “IC” so that you don‟t have to type each individual
hyphen or asterisk. For example, typing “IC **1” inserts a dashed box on the top line of the
line editor. You can also type the command “N” in the editor line where you want to include
the box.

Typing “N” in the editor line the following comment box will be created:

*-------------------------------------------------------
*
*
*
*-------------------------------------------------------

Typing “IC *-*” in the command line inserts a lower-level comment line:

*------------------------------------------------------*

 Comment complex and/or large coding structures by inserting a blocked off comment
section preceding the structure. Here‟s a simple example:

*-------------------------------------------------------
* The following construct performs a SELECT from table
* LFA1 and checks for a return code. If there‟s a
* Return code, the program writes a message to the
* Screen.
*-------------------------------------------------------SELECT * FROM LFA1
WHERE LIFNR = „12345‟.
ENDSELECT
IF SY-SUBRC NE 0.
WRITE: / „The SELECT was unsuccessful.‟
ENDIF

12
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

 When calling online messages, write a comment that includes the message‟s contents.
When using the option Insert Statement (command line IC) for message, SAP automatically
inserts a comment describing the message. For example:

IF SY-SUBRC NE 0.
* This message says „The input file does not exist.‟
MESSAGE E001 (Z1)
ENDIF

 Statements with multiple objects should be indented and aligned for clarity.

 To comment FORMs, refer to the Internal Data Names section of this document.

2.18 Documentation /Text Elements

Always use the Documentation feature and if applicable, use the Text Elements feature of the
ABAP/4 Program Development transaction.

Documentation
Whenever developing a program, always use the Documentation feature. It‟s imperative that
you use this feature to document your programs because business requirements often change
and the specification may not be available to update. To access the program documentation
screen, select the Documentation radio button on the ABAP/4 Editor: Initial Screen. Include the
following components on the documentation screen:

 A complete description of the program

 The program‟s input parameters
 The program‟s dependencies
 The program‟s output
 An example of the program‟s output
 Job running procedures
 Job restart procedures
 Point of contact for problems (team responsible)
 Any special instructions

Note: The ABAP program is not considered finished until it is properly documented. The QA
review has to make sure that the program documentation is done before it can be
released for the functional test.

Text Elements
The use of Text Elements on your program is mandatory. Use text elements every time you
create:
 Headers for output lists,
 Selection text that appears on the selection screen,
 Text symbols which can be used in ABAP statements (E.g. WRITE) instead of literal.
 The use of text elements has important advantages:
 Text Elements are stored outside the program in language dependent text pools. Programs
automatically use the text element of the user‟s logon language.
13
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

 Text Elements are maintained separately from the program.

 The translation of text elements is fully supported by the ABAP workbench. Using the
translator you can create text for different languages.

2.19 Custom Report Layouts

All new reports should include the standard report header.
Only one INCLUDE statement is required and this should be placed before the START-OF-
SELECTION event.
The program to be included is ZWUHDG00 (Note: Last two characters are zeros).

In order to properly use this feature you should maintain your standard report headings in the
ABAP List Heading function.

Additional 6 heading lines could also be specified amongst many other advanced features.

Your REPORT statement must contain NO STANDARD PAGE HEADING.

Your report will default to a default LINE-SIZE = 80 and LINE-COUNT = 64 if it is not specified in
the REPORT statement.

Here is an example:

REPORT ZXXX9999 NO STANDARD PAGE HEADING.

…
…
Data: Field1,
Field2, etc
…
…
…
Include ZWUHDG00.

Initialization
…
…

Start-of-selection
…
…

Example of output

Weekly Production Report Logo

Run Date 01.-03.2009
Run Time 09:20:21
Run By User-Id Value

14
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

Here are the fields printed by the header function from left to right:

First Line
 Report title or program List header
 Company Logo

Second Line
 Run Date
 Run Time
 User Id

3 Online Programming

3.1 Overview
Refer to this section when creating online programs or modifying existing ones. Examples of online
programs are as follows:

 Screens that allow the user to maintain specific edit parameters for document entry.
 Screens that allow updates to Company specific transparent tables.
 New menu options or push-buttons on existing screens.
 New transactions for custom systems

When developing new user interfaces for the R/3 system it is extremely important that the user
interface is consistent with the SAP ergonomics. With the applications becoming more and more
complex, the appearance of the system to the user is becoming even more important. The more we
follow SAP ergonomics less is the user effort to learn how to use these new applications. The
intention behind ergonomics is a user-centered approach. The user should not notice when
changing from a SAP application to a new one (developed by you). The transition must be as
smooth as possible resulting in increased efficiency.

SAP has developed an interesting and useful transaction which developers can reference. The
transaction demonstrates how screens have to be built adhering to standard SAP. Pushbuttons,
check-boxes, field alignment, dialog boxes, header and detail screen and several other screen
elements are shown with respective rules to help you understand SAP ergonomics concept. The
transaction name is BIBS.

The Quality Assurance for a screen is going to check the new development against standards
defined by BIBS transaction. Therefore, a new user interface (screen) cannot be considered
completed until it is in accordance to the ergonomics dictated by SAP.

15
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

3.2 General Guidelines

Here are some general guidelines for online programs:

 When you use the Repository Browser in the ABAP/4 Development Workbench, the system
automatically generates the include programs that contain your screen processing logic
(PBO/PAI modules). In this manner, your program is modular. Also, from the Workbench,
you can access all online programming tools (e.g., screen painter, menu painter,
transaction code maintenance, and the ABAP/4 editor).

 Put all global data declarations in the “TOP” include that the ABAP Workbench proposes for
you when you create your program. Refer to the Module Pool section in the Appendix 3-
Naming Standards for more details.

 Use SAP‟s standard PF keys where applicable. To see a list of SAP‟s standard PF keys,
refer to the PF Keys section in Appendix 3-Naming Standards.

 When creating online messages, try to use the standard message classes within message
repository (e.g., V1 for Sales). Otherwise, create your own according to the Appendix 3-
Naming Standards.

 Be sure to generate your program any time you make changes.

 When laying out your screen in Screen Painter, name the OK code “OK_CODE.”

 When writing text on your screens in Screen Painter, connect each word with an
underscore. Otherwise, each word will be a separate text field.

 Give your title-bars and CUA status‟s the same names as the screens to which they are
assigned.

 Remember that if you want fields on your screen to have Possible Entries (PF4)
functionality, they must have a foreign key relationship with another field in a check table.

 When using fields from the DDIC or from the program use the feature to copy field
templates instead of creating the fields on the screen (from the full screen editor chose Go
to  Dict. /Program fields). This saves time and it is less prone to errors.

4 Enhancements / User-Exit
To begin with, enhancements are not an ordinary type of development because it requires deep
knowledge of the application and solid understanding of the ABAP environment. Therefore, when
dealing with user-exits the developer has to, more than ever, stick to standards. For more details
on the procedures to approve and develop enhancements please refer to the Development Life
Cycle document. It explains in details the approval procedures involved on an enhancement
development.
16
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

To help customers more easily add exits to the core system, SAP has created placeholders within
the standard code. These “place holders” are called user-exits. A great number of user-exits are
grouped in, what SAP calls enhancements. There are four basic types of customer exits within an
enhancement. Each of these exits is a hook where you can “hang” your own add-on. Menu Exit,
Screen Exit, Function Module Exit and Keyword Exit are types of exits contained in the
enhancement.

Another type of exit is the Program Exit. These exits are placed in specific module pools but their
content is empty. Because these exits are not supported by the enhancement concept detailed
documentation is needed. Some of these exits are very generic about what you can do. The
consequence of this flexibility is that some exits might be used to solve more than one business
requirement. Therefore, it is advisable that comments are used to document the code. You can
copy an existing template into your own code. Select the option Insert Statement in the Edit menu
option or press CTRL + E. Then, click on Other Patterns and choose Z_USER_EXIT_TEMPLATE.
This template includes all the fields that should be documented when creating a user-exit. Please
find on the Appendix 2, the user exit template that has to be used.

The user exit documentation should contain the following information:

Development ID: The Status Tracking Tool (STT) ID number assign to the development request.

Dev. short Desc: The short description given in the STT database.

Author‟s Name: The developer coding the program.

Last Update: The last time the program was updated.

Request #: The SAP transport request which exit was assigned to.

Description: A brief description of the functionality to be performed in the user exit with
input and output fields.

Here are some guidelines that must be complied with when working with user exits:

1) DO NOT experiment in Development & Quality. If you are just trying or experimenting (proof of
concept), make an effort to work as much as possible in the sandbox system (e.g. Sandbox
system) or whatever designated sand box system.

2) Only develop in Development & Quality when 100% sure. If no test is possible in the sandbox
or if you completed your testing in that system, then and only then, go to one of the
development boxes.

3) Make sure the User Exit is the correct one. Choose your enhancement carefully. If the User Exit
you desire is not available in one of the standard enhancements (transaction SMOD), choose it
carefully by making sure the transaction processing passes through that code.

4) While developing make your code only executable under your own User ID including a CHECK
statement. When ready to start coding make sure you put the following condition before your
17
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

ABAP code: CHECK SY-UNAME = ‘<your user id>’. This is to guarantee that your code will
only be executed when you are running the transaction/user exit. The User Exit won‟t be
available for the rest of the users.

5) Be careful when the User Exit is being used already. If the same User Exit is being used by
other person, DRF or project is twice as careful. There are two situations that apply here: (A)
the user exit has been released / transported and therefore there is no CHECK statement
against the developer‟s user id anymore. In this case, just include the CHECK described in item
4. (B) The user exit you are about to change is currently being developed/tested and, therefore,
it already contains another developer ID‟s check. In this case, just add your ID on the same
check.

6) DO NOT activate projects with syntax errors. If you are working with project/enhancement
always make sure that there are no syntax errors before activating it. Even if it is for a brief
moment, these syntax errors might annoy several people across several modules.

7) Demand a check by the Design Team. Because of the nature of User Exits, make sure you get
an approval for your work with the design team members involved. Ask them to check all the
transactions that might have been affected by that user exit you‟ve worked on. They might not
know them all but they will have a pretty good idea.

8) Remove the CHECK statement when clear. After Design Team approval of the solution, make
sure you remove your CHECK statement. It will be very embarrassing to learn your check was
transported to Production and only yourself can see the result of your master-piece ABAP code.

9) When your situation does not really fit under this discussion or if the user exit you are working
on is too complex with pieces of ABAP code that must be executed in certain situations but not
in others. For example, there might be cases when the use of IF SY-UNAME = „<your user id>‟
will be more appropriate than CHECK. The idea behind is that you isolate your code until you
are completely sure of the effects in the whole system/project.

5 SAP Script / Smartform Programming

When changes in a SAP delivered layout set are necessary make sure you copy the existing layout
set and program to customer defined names. Never change SAP object, instead change your
copied ones.

When building a form using SAP script, use the LETTER page format. If you use another format,
like INCH12, there could be some problems with text wrapping.

Please refer to the Appendix 3 - Naming Standards when naming SAP script layout sets and
Smartform programs.

18
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

6 Function Modules
Never create a new function module if one already exists that will perform the required task. Always
use the function builder to search for existing function modules. Remember that someone might
have thought about doing what you want to do.

All function modules must have their EXPORT, IMPORT, TABLES and EXCEPTION parameters
documented. The function module itself also needs to be documented using the “Documentation”
on the function builder.

Important: when creating function modules are sensitive to the number of functions within a
function group. Whenever a function module is called the entire function group is loaded in
memory. If necessary, create a new function group. Keep similar function modules within the same
group. For instance, function group “Z_EMAIL” contains modules “Z_SEND_EMAIL”,
“Z_RECEIVE_EMAIL”, etc.

7 Recommended Programming Techniques and Constructs

This section of the document contains programming constructs and techniques that you should use
to ensure that your code executes efficiently and is as “bulletproof” as possible. This section is not
intended to cover everything concerning to programming techniques. It is instead, a reference
including the most important facts. Another good source of information is the section “Tips &
Tricks” within the R/3 Runtime Analysis. You will encounter several performance comparisons
between different code constructions. This will help you build an efficient and cleaner code, as well.
The recommended techniques and constructs for efficient programming are as follows:

7.1 Database Operation

 Changing a standard table – When changes to a standard table/structure are necessary,
use the APPEND feature (never change a table). Due to the fact that some of these
tables/structures are included in other SAP tables, a global activation is sometimes
necessary. In this case only the SCC/PS has authorization to do it. The activation must be
done by a DBA. Please contact SCC/PS via E-mail for activation of appended tables.

Note: Please note that there will be some special situations:

Depending on the change you want to perform in the standard table/structure, a full conversion
of all tables affected is required (with deletion of indexes and tables and consequent re-build of
these objects with the new structure). This is a dangerous procedure and some attention is
required. If the change you are performing in a standard table involves:

(A) Deletion of Field,

(B) Shorten field,
(C) Reduce decimal places,
(D) Deletion of key field, or,
(E) Remove key field from key,

19
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

A full adjustment of the SAP table (and its dependent structures) has to be performed in the
database level. In this case, you have to instruct SCC/PS to perform the activation after hours
when nobody is logged into the system. If this is not followed data might be corrupted and
sessions might be crashed with short dumps. Ultimately, the restore of back-ups with
consequent system downtime might occur.

 If the full key is available when performing SELECT statements, use SELECT SINGLE. In
this manner, you are only extracting the database record that you‟ll be using instead of
performing unnecessary data retrieval. Also, the SELECT SINGLE performs better than a
straight SELECT.

 When use SELECT, always specify your conditions in the WHERE clause instead of
checking yourself with CHECK statements. The database system can then use an index (if
possible) and the network load is considerably less. Also, the order of fields in the “WHERE”
should follow the order of fields in the DDIC table.
e.g.:
SELECT * FROM BKPF
WHERE BUKRS = „0800‟.
ENDSELECT
Not.
SELECT * FROM BKPF.
CHECK BKPF-BUKRS = „0800‟.
ENDSELECT

 It is always faster to use SELECT … INTO TABLE than APPEND. However, if the table
used in the INTO TABLE version does not have exactly the same layout of the table being
read use INTO CORRESPONDING FIELDS…. .

 If you have a large internal table in your program, it is a good practice to keep it sorted if
single lines are read at random during runtime. You can fill the table so that it is pre-sorted
by the primary key. This keeps single access fast. However, if you always loop through all
lines the table, sorting that table is not really necessary. For more details, refer to help of
commands SELECT … ORDER BY and SORT.

 Must use ENQUEUE and DEQUEUE logical locks for database table modifications.

 Whenever possible, use column updates instead of single-row updates to update your
database tables instead of selecting each record and updating. Network load is
considerably less. UPDATE dbtab WHERE is faster than SELECT WHERE … UPDATE.

 When programming database updates, the use of Logical Unit of Work (LUW) concept is
mandatory. By doing so, you guarantee the database consistency. Updates within the same
LUW are either fully executed or not at all (rollback). If an error within the LUW database
occurs the initial status is reestablished to what t used to be before the LUW. For more
information on this topic please refer to the Programming Database Updates in the R/3
library.

 You should use Logical Databases, whenever possible. There are several advantages to
using Logical Databases including performance and ease of use. However, a program can
20
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

run faster with SELECTs depending on the order you want to retrieve data out of the
Logical database structure and the level your checks are performed at. Developers should
carefully choose one of the two techniques or even a mix between LDB and SELECTS.
This is especially true when reading large tables like BSEG and MSEG.

 Do not use GET command if you are not reading an entire logical database sequentially. In
this case, a SELECT would enable the user to retrieve the information much faster.

7.2 Control Events

 When checking a field against several possible values, you can use either the nested IF or
the CASE statement. The CASE statement is better for two reasons. It is easier to read
and after about five nested IF‟s, the performance of the CASE statement is much better.

 When coding IF statements, nest the testing conditions so that the outer conditions are
those that are most frequently true. For logical expressions with AND, place the most likely
false part first.

 Use the EXIT command to leave a loop structure as soon as a specified condition is met.
This reduces needless loop processing.

 Use the ON CHANGE OF command instead of developing code to compare current and
previous values of a data field within SELECT/ENDSELECT processing or GET events.

 Use the CHECK command instead of an IF statement whenever possible. This reduces
processing time and improves readability.

7.3 Internal Tables

 If you need the COLLECT semantics, DO use COLLECT. The logic used by the COLLECT
statement is independent of the number of entries and it does not need to maintain a table
index.
 When sorting internal tables, specify the fields to be sorted.

SORT ITAB BY FIELD1 FIELD2

 To find out how many entries are in an internal table, use the DESCRIBE command.

 When you no longer need an internal table in your program, use the FREE command to
delete the table completely out of memory. In this manner, system resources will be freed
up to more efficiently process the rest of your program.

21
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

7.4 General Constructs / Techniques

 Whenever possible, use MOVE instead of MOVE-CORRESPONDING command. The

MOVE command has slightly better performance than the MOVE-CORRESPONDING
command. When using MOVE within a process block try to avoid field conversions (moving
fields of different types). For instance, moving a character field to an integer takes 5 times
longer than between character fields. When this move is executed several times inside a
process block a sensible difference in time response might be noticeable.
 For readability, replace blocks of code within a long IF statement with PERFORMs.

 For effective modularization, code your program so that PERFORM statements are within
an IF statement. By doing this, you won‟t call the subroutine unless the IF tests fails. For
instance, example “A” is better than example “B.”

A. IF FIELD1 NE 0.
PERFORM SUB1.
ENDIF
FORM SUB1.
...
ENDFORM

B. PERFORM SUB1.
FORM SUB1.
IF FIELD1 NE 0.
...
ENDIF
ENDFORM

 Avoid leaving “dead code” in your ABAP. Remove defined fields that are never referenced
and code that can never be logically executed. To see if a declared field is used anywhere
in your program, double-click on it.

 Use the ABAP/4 Runtime Analysis feature to ensure that your program is running as
efficiently as possible.

 When you‟re indenting nested statements (by 2 spaces), use the Pretty Printer function,
which indents all nested statements in your code by 2 spaces. To invoke the Pretty Printer
function, type “PP” on the command line and press ENTER or, choose it from the menu.

 The SAP system provides a large number of function modules to support standard Dialog
Boxes. Several functions are available for different type of dialogs. For details please refer
to the Extended Applications Function Library in the R/3 Library.

 We recommend that you work with local data as often as possible. The usage of local data
increases the readability of the source code.

22
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

 Whenever possible use the “Extended Program Check” feature from within the ABAP editor
(Program  Check  Extended Program check). The extended program check makes
static checks that are too laborious for the normal syntax check. When you choose "Perform
check", the checks selected in the "Checks" group box are carried out. If you choose
"Perform std. check", the system reports those errors that are particularly critical.

 Runtime Analysis – Upon completion of your transaction/report you should analyze your
coding utilizing the Runtime Analysis. This tool checks the performance of your code
created within the ABAP workbench. The Runtime Analysis tool creates lists that reveal
expensive statements, summarize table accesses, and show the hierarchy of a program‟s
flow. These are some of the problems that can be detected using this tool:

– Inefficient and unnecessary database accesses,

– CPU-intensive programming functions,
– Overuse or unnecessary calling of modularization units,
– User-programmed functions that replace existing ABAP statements.

Use the SQL Trace tool when you want to check the program‟s database accesses. Improper
written SQL statements have a great impact on application performance. By using this tool you
can analyze potential problems and make the necessary correction.

23
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

8 Appendix 1

Program Change log history

Following is the change log history to be maintained at the start of the
program:

*------------------------------------------------------------------------------*
* Program Name : <Program Name> *
* Title : <Report Title> *
* Development class : Z<XY> *
* Transaction Name : <Transaction Name> *
*------------------------------------------------------------------------------*
* Description : <Report Title> *
*------------------------------------------------------------------------------*
* Change Log *
*----------- *
* *
* TR Number Date Author Description *
* --------- ---- ------ ----------- *
* <TR Number> 12-12-2005 <Author Name> <TR Description> *
* *
*------------------------------------------------------------------------------*

Note: XY in Development class is to be replaced with the respective module names.

SD – Sales and Distribution; FI – Finance; PS – Project Systems; MM – Materials Management;
CO – Controlling; PM – Plant Maintenance; HR – Human capital management

9 Appendix 2

User Exit header template

*----------------------------------------------------------------------------*
*Development short description: *
*Author‟s Name: *
*Last Update: *
*Development Request #: *
* *
*Description: *
* ... *
*----------------------------------------------------------------------------*

24
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

10 Appendix 3
ACC Program Naming Standards
Report / Program Naming Standards: Z<DEV ID>_<Report Description>

 DEV ID – Capture from LLD

Note: Remove ‘ACC’ from DEV ID and replace all hyphen ‘-’ with underscore ‘_’.
 <Report Description> This has to be replaced by a suitable report or program description.

Tables Naming Standards: Z<DEV ID>_<H/D/T>_<Description>

 DEV ID – Capture from LLD
Note: Remove ‘ACC’ from DEV ID and replace all hyphen ‘-’ with underscore ‘_’.
 H/D/T to be replaced with:
H if the table is Header table
D if the table is Detail table.
T if the table is Transactional data table (table created as a standalone single table or
it‟s a temporary table to store temporary transactional data)

 <Description> to be replaced with a suitable program related description.

25
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

11 Appendix 4
Naming conventions in Reports, Enhancements & Forms

S.No Data Type Prefix Example

1 Internal Table IT_ IT_PA0001

2 Types TY_ TY_ADDRESS

Work area for database and

3 WA_ WA_MARA
internal tables

4 Structure ST_ ST_P0001

5 Ranges/Type Range Of RA_ RA_MATNR

6 Table Control TC TC_9000

7 Data reference DR_ DR_UZEIT

8 Reference Variable RF_ RF_SALES

9 Select-Options SO_ SO_VBELN

10 Parameters PA_ PA_POSNR

11 Constant CO_ CO_LANGU

12 Local Variable LV_ LV_LIFNR

13 Local Class LC_ LC_BUILD

14 Local Interface LI_ LI_FRONT

26
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

Naming Conventions in ABAP Objects

Global classes and interfaces that you create in the Class Builder are stored in the class library and
administered by the R/3 Repository: they therefore have the same namespace as all other
Repository objects (database tables, structures, data elements, and so on).
It is therefore necessary to have naming conventions for object types and their components and to
use them uniformly within program development.

The following naming convention has been conceived for use within the SAP namespace:
If you do not observe the naming conventions for object types (classes and interfaces), conflicts will
occur when the system creates persistent classes, since it will be unable to generate the necessary
co-classes.

Namespace for Components

A single namespace within a class is shared by:
All components of the class itself (attributes, methods, events, constructors, interfaces,
internal data types in the class, and aliases)
All public and protected components of the super classes of the class.
Method implementation has a local namespace. The names of the local variables can obscure
those of class components.

Naming Convention
The naming convention has been kept as general as possible to avoid adversely influencing the
naming of objects.

General Remarks
When you choose names for development objects, you should:
Use English names
Use glossary terms when possible

For example, CL_COMPANY_CODE instead of BUKRS

In compound names, use the underscore character (_) as a separator. Since names are not case-
sensitive, this is the only character that you can use to separate names.

Example: CL_COMPANY_CODE, CL_GENERAL_LEDGER_ACCOUNT

Names should describe the action, not the implementation of the action.

Example: PRINT_RECTANGLE, not RECTANGLE_TO_SPOOL

27
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

Conventions for Object Types

Class and interface names in the class library belong to the same namespace as data elements,
tables, structures, and types. They are maintained centrally in table TADIR.

CL_<class name>

Class in the class library The class name should be made up of singular nouns.

CL_COMPANY_CODE,
CL_GENERAL_LEDGER_ACCOUNT

IF_<interface name>

Interfaces in the class The same naming convention applies to interfaces as to

library classes.

IF_STATUS_MANAGEMANT, IF_CHECKER

Local classes in
LCL_<class name>
programs

The class name should be made up of singular nouns.

LCL_TREE_MANAGEMENT

Local interfaces in
LIF_<interface name>
programs
The sane naming convention applies to interfaces as to
classes.

LIF_PRINTER

28
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

Conventions for Components

<method name>

Method name Method names should begin with a verb:

GET_STATUS, CREATE_ORDER,
DETERMINE_PRICE

<event name>

Event names should have the form

Events
<noun>_<participle>:

BUTTON_PUSHED,
COMPANY_CODE_CHANGED,
BUSINESS_PARTNER_PRINTED
TY_<type name>
Local type definitions within a
class (recommendation)
TY_INTERNAL_TYPE, TY_TREE_LIST

<variable name>

Data definitions (variables) When you name variables within a class

(CLASS-DATA or DATA), avoid using verbs at
the beginning of the name (to avoid conflicts
with method names).
LINE_COUNT, MARK_PRINTED,
MARK_CHANGED, STATUS

CO_<constant name>
Data definitions (constants)
(recommendation) CO_MAX_LINE, CO_DEFAULT_STATUS,
CO_DEFAULT_WIDTH, CO_MAX_ROWS

29
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

Concrete Method Descriptions

SET_<attribute name>, GET_<attribute

name>

Methods that access attributes of any kind

Attribute access
should be prefaced with GET_ or SET_.

GET_STATUS, SET_USE_COUNT

ON_<event name>

Methods that handle events should begin with

Event handler methods ON, followed by the name of the event that
they handle.

ON_BUTTON_PUSHED,
ON_BUSINESS_PARTNER_PRINTED

AS_<new type>
Methods that perform type
conversions
AS_STRING, AS_ISOCODE

IS_<adjective>

Methods that return a Boolean value

IS_OPEN, IS_EMPTY, IS_ACTIVE

CHECK_<objective>

Check methods
CHECK_AUTHORIZATION,
CHECK_PROCESS_DATE

30
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

Local Conventions With in Methods

For parameters
The parameters are regarded from the point of view of the method that implements them:

IMPORTING parameters IM_<parameter name>

EXPORTING parameters EX_<parameter name>

CHANGING parameters CH_<parameter name>

RESULT RE_<result>

12 Appendix 5
For exceptions

The following table contains a series of possible exception names that can also be used generically
(for example, NOT_FOUND could also be used as DATE_NOT_FOUND)

EXCEPTION Meaning

ACTION_NOT_SUPPORTED The requested action or function code is not supported.

If a method uses a dialog to find out what has to be dome (for

CANCELLED example, a list of choices), and the user chooses "Cancel", you can
set this exception.

EXISTING A new object that you want to create already exists in the database.

The method could not be executed because of the current

environment. This exception is intended for cases where the
FAILED
method cannot be executed because of variable system
circumstances.
Part of the method could not be completed because of the current
..._FAILED environment. (OPEN_FAILED, CLOSE_FAILED,
SELECTION_FAILED, AUTHORIZATION_FAILED)

FOREIGN_LOCK Data is locked by another user.

INCONSISTENT Object data in the database is inconsistent.

The component data for … of an object in the database is

..._INCONSISTENT
inconsistent.
31
 SAP@RRAB
Programming Standards and Guidelines
ACC - ABAP Programming Standards and Guidelines - V 1.0
20100119
Created By: Thangeswaran T.K Created : 19 January
2/1/2010
2010
Document : ACC - ABAP Programming Standards and Guidelines - V 1.0 20100119 UPDATED : 1 FEBRUARY 2010

The object data entered is incorrect (for example, company code

INVALID
does not exist). Compare NOT_QUALIFIED.
The component data entered for an object is incorrect. Compare
..._INVALID
NOT_QUALIFIED.
Last resort. Only use this exception if you cannot be more precise
INTERNAL_ERROR
about the nature of the error.

NOT_AUTHORIZED The user does not have the required authorization.

NOT_CUSTOMIZED The object requested is not correctly customized.

The component … of the requested object is not correctly

..._NOT_CUSTOMIZED
customized.

NOT_FOUND Unable to find the requested object.

..._NOT_FOUND Unable to find component … of the requested object.

The combination of input parameters is insufficient to run the

NOT_QUALIFIED
method. Compare INVALID.

..._NOT_QUALIFIED One parameter of the method is not qualified.

NUMBER_ERROR Error assigning a number.

This exception is set if the Basis system returns an unexpected

SYSTEM_ERROR
error message.

13 Appendix 6
Change and Transport System Standards

Transport Name (for Production) T-ABAP-<Object Name>- Short description-001-<Initial>

Transport Name (Not for
NT-ABAP-<Object Name>-Shortdescription-001-<Initial>
Production)

1. T – Transport to Production; NT – Not for Production

2. Dev ID - Development id
3. Object Name - Development object Name
4. Short description - Short description of object
5. 001 - Version of transport (001 for first time)
6. Initial – Transport Owner Initial

32