Z abap coding_standards_v2_0_t

ABAP Coding Standards
Reference Guide
August 2010

Reference Guide | 1ABAP Coding Standards
CONFIDENTIAL
ABAP Coding Standards - Reference Guide. Vers. 2.0
Copyright © 2010. CodeExcellence Inc. All Rights Reserved
Introduction This document provides a quick reference to ABAP coding standards and expectations for
new SAP™ development. The standards represent a minimum requirement and are
intended to be an adjunct to other commonly accepted best practices in the industry. The
corporate coding rules, which are described in the document, can be monitored using the
HAWKEYE™ Monitor tool.
A key element of the coding standards and application governance methodology is the
application of an automatic code review process using HAWKEYE™. The Hawkeye system
continually scans code, generates real time reports, and delivers alerts to management. In
addition, developers can use the APOD tool. It helps ABAP programmers ensure their
code is consistent with corporate expectations, quickly and efficiently.

CONFIDENTIAL
ACCESS CONDITION WITHOUT ALL
KEYS
This rule covers both, SELECTs from database tables and READs from internal tables.
Single rows in internal tables are accessed with a READ TABLE statement. All READs
access the internal table by numeric index or with an internal table key. For READs with
an incomplete or incorrect key there may be mulitple rows that satisfy the partial criteria.
In this case the READ statement returns the first matching row. This may not match the
expected result.
Select Single should provide all fields of the Primary Key. The purpose of a select single
is to retrieve a single unique row based on the unique primary key fields(s). Without all
key fields specified, there may be multiple rows that satisfy the partial key criteria resulting
in any one of the rows being returned. Therefore, the specific record expected may not
be the one returned.
ACCESSING ABAP MEMORY
WITHOUT ID
Programs should always reference ABAP Memory by a unique ID. Referencing Memory
generically can have impact on other applications using ABAP memory i.e. FREE
MEMORY without an ID would wipe out all ABAP memory which could affect other
programs that are counting on data in memory.
ALV LIST VIEWER Use ABAP List Viewer instead of Classic Lists. WRITE statements and classic report
writing techniques are obsolete and should be replaced with ALV programming using the
SAP List Viewer Object model. Complete ABAP™ OO programming is supported using
SALV that delivers user flexibility for output format, feature rich programming, and end
user capabilities without the need for additional programming. The area of report writing
has gone through several progressions. As a programmer you will encounter all flavours
of report programming as listed below.
• Classic List reporting using Write statements
• The first introduction of ALV with the REUSE* functions
• This was then replaced with the Class based ALV using CL_GUI_ALV_GRID
• And now a complete delivery of the ALV object model called SALV.
All new report programming should use SALV* classes
AMBIGUOUS FIELD NAME Avoid using field names that are the same as pre-defined SAP TYPES (N, I, F, D, etc) or
operators.
ARITHMETIC OPERATORS INSTEAD
OF WORDS
Use operators (+, -, *, /, =) rather than the obsolete words ADD, SUBTRACT, MULTIPLY,
DIVIDE, MOVE.
ASSIGNMENT HAS NO EFFECT Avoid assigning variables to themselves. There is no effect from this practice.
BREAK-POINT STATEMENT
DETECTED
All break-point statements must be removed prior to production. This could potentially
stop production and provide back door access (I.e. debugger) into the code and
confidential data.

CONFIDENTIAL
BUFFER INVALIDATED Tables buffered in the SAP table buffer should be changed as seldom as possible. In
certain cases, local changes of a few records in a table can cause invalidation of the table
in the buffer in other application servers. This will result in entries no longer being current
in the buffer and will therefore have to be imported again from the database. Avoid any
of the following scenarios that will invalidate the buffer:
• UPDATE/DELETE with a WHERE on single-record-buffered table.
• UPDATE/DELETE dbtab, UPDATE/DELETE dbtab FROM WA and UPDATE/DELETE
dbtab FROM ITAB each invalidate only the specified records
• UPDATE/DELETE with a WHERE invalidates the entire table in the buffer.
• UPDATE/DELETE with a WHERE on generically buffered table and generic key not
fully specified.
• UPDATE/DELETE with a WHERE, and the generic key in the WHERE condition is not
fully specified, all the generic areas of the buffer are invalidated.
• INSERT/UPDATE/MODIFY/DELETE on completely buffered table.
Each change of a completely buffered table invalidates the table in the buffers of the
other application servers of the system. If the parameter "Only 'buffering switched on' " is
set in the check, accesses to tables that allow the option 'buffering' in their technical
properties, but have 'switched off' set, are not checked.
BUFFERED TABLE IN A JOIN Avoid the use of Buffered Tables in a Join. This will cause bypass of the buffer.
BUFFERED TABLE IN SELECT WITH
SUBQUERY
Avoid the use of buffered tables in a sub query to avoid bypassing the buffer.
BYTE & CHARACTER STRINGS Use the variable length statement STRING and XSTRING when declaring character and
byte data variables. It provides better use of memory than fixed length text statements
TYPE C and TYPE X.
CALL TO EDITOR All EDITOR calls must be removed prior to production.
CASE VERSUS IF Use the CASE statement rather than IF/ELSEIF/ENDIF construct when there are multiple
= conditions. If there is only one condition, then the IF/ELSE/ENDIF statement is a good
choice.
CASE WHEN FIRST STATEMENT WHEN must be the first statement after a CASE statement.
CASE WITHOUT WHEN OTHERS Case Statement requires a “When Others” clause. Any condition that is not met will have
a fallout path. In the “When Others”, always provide an action or a generic message so
that the program can announce that an unexpected situation has been encountered.
CATCH - PROCESSING MISSING Processing section inside the CATCH … ENDCATCH block is empty. Exceptions must
be explicitly handled within the CATCH … ENDCATCH block. Add the required exception
processing between CATCH and ENDCATCH

CONFIDENTIAL
CLIENT SPECIFIED LIMITED TO
SYSTEM TOOLS
In Multi-Client production systems, regular ABAP application programs should never
select data across clients with the CLIENT SPECIFIED option since there’s a risk with
mixing data across clients / companies. Standard SAP always stays within a client for
regular application data and therefore custom code should follow the same rule. The use
of CLIENT SPECIFIED should be limited to system tools.
CLIENT SPECIFIED TABLE FIRST
FIELD
This is a Data Dictionary Requirement that Client Specified Tables MUST have the first
field of the table defined as CLIENT (MANDT).
CODING BLOCK EMPTY Do not create empty coding blocks inside blocks such as IF...ENDIF, WHILE...ENDWHILE,
SELECT MAX, etc. Empty coding blocks add no value and are considered maintenance
overhead.
COMMON PART STRUCTURE
DEFINITION INCONSISTENT
Identically Named Common Parts must have the same structure definition.
COMPONENT NOT ASSIGNED TO
AN ENHANCEMENT
Function Module must be assigned as a component of a CMOD enhancement.
CURRENCY CLAUSE When outputting numbers that are tied to currency, always use the CURRENCY formatting
option. This will set the number of decimals according to the currency of the country.
CUSTOMER DEFINED MACROS
NOT RECOMMENDED
Operational issues in Macros that cause Program Dumps are difficult to trace. Wrap the
reusable code in a method instead.
DANGEROUS HIDE ON A FIELD
SYMBOL
Avoid using field symbol with a HIDE statement. If field symbol is not assigned,
unpredictable results can occur
DATA VARIABLES - USE OF
DEFAULTS
Do not use implied defaults on data declarations. Be explicit when TYPING your data
variable. Always Specify the TYPE and Length
DATA VARIABLES - USE OF TYPE
VS LIKE
Use keyword TYPE when declaring data objects rather than LIKE (which is an old
convention). LIKE should only be used when a data declaration refers to an existing data
object defined in your program. LIKE is also commonly used for declaring the line type of
an internal table i.e. LIKE LINE OF.
TYPE is a common convention found in most other modern programming languages.
Note: In OO porgramming, any reference to a dictionary type MUST use the keyword
TYPE. LIKE will fail syntax check.
DATABASE ACCESS INSIDE A LOOP Avoid database accesses inside a loop to minimize performance issues.
DATABASE UPDATE WITHOUT
UPDATE MODULE
Updates to the database should be encapsulated in V1 or V2 Update function modules.
This provides full recovery and logging of activity when performing INSERT, UPDATE,
MODIFY and DELETE of Database tables.

CONFIDENTIAL
DATABASE UPDATES INSIDE A
LOOP
Replace Updates inside a loop with a single set level process update to the Database
outside of the loop. This will reduce the trips to the Database and improve performance.
DATE FORMAT UNSUPPORTED Do not reference unsupported date formats. The only valid supported date formats are
found in USR01-DATFM
DEAD CODE Remove unused code unless it is required for documentation.
DIRECT UPDATE TO SAP TABLE Under no circumstances should any program directly update SAP delivered tables.
Updating of SAP tables should be performed using pre-delivered API's that perform the
update
DUPLICATE DEFINITION Avoid Duplicate Definitions for all objects and declarations. It is redundant, causes
Maintenance issues, and possible extraneous processing with unpredictable results.
DUPLICATE WHEN CONDITIONS Never duplicate a WHEN condition. Unexpected program behavior could result with
duplicated WHEN conditions.
DYNAMIC CALLS TO PROGRAMS Dynamic Calls to programs can lead to production failures if program or object does not
exist. Without proper exception handling, this is a dangerous practice.
DYNAMIC TABLE ACCESS Always Include Exception Handling when accessing Tables Dynamically. Dynamic Calls
can lead to production failures if the call can not be resolved or object does not exist.
Dynamic Table access can be a very a dangerous programming practice if proper
exception handling is not in place.
ESSENTIAL PRINT PARAMETERS Essential Print Parameters are missing. Unexpected results can occur without the
essential print parameters. Essential required print parameters are:
Name of printer (DESTINATION)
Number of copies (COPIES)
Spool identification: Name of spool request (LIST_NAME)
Text of spool request (LIST_TEXT)
Spool control: Deletion of the spool job after print output (RELEASE)
Archiving mode (ARCHIVE_MODE, 1 = print, 2 = archive, 3 = print and archive)
New spool request, this means do not append to an existing request (NEW_LIST_ID)
Format specifications:
Column number of a print page(LINE_SIZE)
Lines per page (LINE_COUNT)
Print output format (LAYOUT)

CONFIDENTIAL
EXCEPTION HANDLING - USE
CLASS BASED
Use Class Based Exception Handling Techniques. CATCH … ENDCATCH is obsolete.
Errors should be anticipated and handled in all program code. The nature of errors varies
and could be caused by incorrect implementations internal to the program or external
interactions such as input errors or unexpected resource limitations (E.g. files,
memory).
All runtime errors (E.g. zero divide, conversion errors, …) raise class-based exceptions
and should be captured and handled in program code with the CATCH statement in a
TRY/ENDTRY control block.
EXCEPTION HANDLING GENERIC
MESSAGE AFTER FUNCTION CALL
Generic Messaging after a function call is not recommended. Anytime the PATTERN
function in the workbench is used to insert a function, it automatically inserts a generic
message of the form:
"MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno WITH sy-msgv1 sy-msgv2,
sy-msgv3, sy-msgv4”.
This statement assumes that SY variables have been filled with meaningful values by the
function itself. However, often times, this is not the case and the message will be
meaningless.
The generic message should only be used in the case where the function and all nested
functions that are called use the Message...Raising format consistently throughout the
function chain. The Message...Raising format sets the sy-message and other sy variables.
Only then, can you be assured that a generic message statement can be used to present
a proper error message. However, since this situation is most likely not the case, a good
developer will handle the message themselves and not count on the generic format to
provide a meaningful message relevant to the situation.
EXCEPTION HANDLING MISSING
OR WRONG EXCEPTION
ABAP Statements that can potentially cause program dumps require that the correct
exception for the statement as per the SAP Help must be caught and handled to avoid
dump situations. Ensure that a Try/Endtry is in place to catch the exception.
Note: CX_ROOT as a catch all exception is not a recommended practice.
This check ensures that the CORRECT EXCEPTIONS are handled for the following
statements: REPLACE, COLLECT, SORT, FIND, ASSIGN, CREATE, Dynamic SELECT,
and Dynamic METHOD
EXCEPTION NOT CAUGHT OR
DECLARED
The exception is neither caught nor declared in the RAISING clause of the procedure.

CONFIDENTIAL
EXCEPTION NOT PROCESSED There may be cases where SAP delivered functions do not have defined exceptions. It is
still recommended to provide exception handling when Calling the function. This enables
that the code still works without a run-time error in the event that SAP adds an exception
to the Function Module interface. For example the application of an OSS Note is able to
introduce a new execption for the function module. Setting all exceptions to 0 in the CALL
FUNCTION statement is not a good practice because it basically ignores the
exceptions.
The programmer should always check the exception returned from a function. DO NOT
not count on an importing parameter being returned to the calling program as a sign of
successful execution. An assumption holds true that a field is not set if an exception is
returned, but that could change during a future enhancement of the function.
Exception: Excluded from this rule are system functions that don't return any exceptions,
i.e. function module DEQUEUE. For these system functions that do not have defined
exceptions, it does not make sense to check for SY-SUBRC after the function call.
Note: Customer defined functions should always have Exceptions defined.
Recommendation:
==> If a function module has exceptions defined, you have to handle them. An empty IF
statement is not enough
==> If a function module has no exception defined, CodeExcellends recommends
using EXCEPTION OTHERS = 1 and handle the exception
==> If a function module has no exception defined, and the programmer is not
using EXCEPTION OTHERS = 1 you can't check sy-subrc after the function module call
since the sy-subrc will not be set by the function call
EXTERNAL CALLS External calls to subroutines are forbidden. In the case of short dumps, the ability to
debug external calls is restricted and Production support therefore becomes more
difficult.
EXTRACT FILES Extract Files are considered Obsolete. There is no need to use this old style array
processing technique
EXTRACT files are a convenient way of dealing with internal tables of different structures
that have same or similar keys. The same can be achieved with internal tables. Only one
EXTRACT file can be used per program.
FIELD IS UNKNOWN Only fields that are defined or in a specified table can be referenced. Any reference to
fields that do not exist will cause syntax issues.
FIELD NOT A PARAMETER OR
SELECT OPTION
The parameter / select-option in the SUBMIT statement does not exist on the selection
srceen of the called program. Verify that the parameters and select options match
between the SUBMIT statement and the called program selection screen

CONFIDENTIAL
FIELD SYMBOL NOT ASSIGNED A field symbol was defined but not assigned. If the field symbol is not used, then it should
be removed.
FILE OPERATIONS - LOGICAL FILE
NAMES
Use the logical file concept instead of hard coded physical file names. The function FILE_
GET_NAME must be used to translate the logical file name to the physical path and file
name.
Logical filenames are mapped to physical filenames using transaction FILE. Dynamic
parameters are available to i.e. client, instance, etc. to ensure file names meet file naming
conventions and the programs that use the files work across all system boundaries.
FUNCTION GROUP INCONSISTENT All components of a Function Group must pass internal consistency check. If the
consistency check error occurs, it is possible that some internal objects have been
corrupted. This can result in the function module not being stored in the database table
TFDIR or possibly stored under a different name.
FUNCTION MODULE OBSOLETE Using Obsolete Function Modules should be avoided. It will cause upgrade issues as
they are not forward compatible or supported by SAP™.
FUNCTIONS WITHOUT
EXCEPTIONS
When Calling a function, always include the exceptions clause. There is no value in
checking sy-subrc if the exceptions clause is not part of the CALL Function statement.
Don't add an empty IF SY-SUBRC = 0 ... ENDIF block or a CHECK SY-SUBRC = 0 after
a function call without exceptions. A function should be defined with exceptions unless it
is a special purpose function such as update task, asynchronous, RFC, etc.

CONFIDENTIAL
HARD CODING When the same text literal is used repeatedly in an arithmetic or logical expression,
define the value as a Constant instead of a text literal and name the constant descriptively.
This check determines if their is hard coding contained in the following statements:
SELECT, DELETE, SORT, LOOP, WHEN, IF, READ.
Corporate processes change. So do the business values used in daily operations. For
example, it is very common to experience changes to business config items such as
document types, org level definitions, cost centers, company codes, plants, etc. Therefore
it is highly recommended to avoid ‘Hard Coding’ of any business values required in your
program.
Where possible, use existing SAP tables to provide business values to the program and
use a SELECT statement to retrieve those values into an internal table. If an SAP table
is not available with the required values, then it is advised to build a custom Z* table to
contain the required business values. There are significant benefits to this approach
when it comes to maintenance. When a business value changes, then maintenance is
performed on the custom table (once) rather than all instances of programs that use the
business values. Customer defined business type tables should try to use data elements
that are already used in like fields in other SAP tables.
If the above approach is not followed and it is decided to hard code business values in
the program then at minimum, the hard coded value should be defined as a constant and
named descriptively.
HYPHEN DETECTED Avoid the use of the hyphen in a declared variable name. It is normally used as a
dereferencing operator.
IGNORED EXCEPTIONS CLAUSE The EXCEPTIONS clause is ignored for asynchronous update function modules. Clean
up the function by removing the superfluous Exceptions.
ILLEGAL NUMBER CONVERSION Non numeric fields should not be converted into numbers. This could result in a run time
error with a program dump.
ILLEGAL USE OF OFFSET A length declaration is required when using offsets.
INCOMPATIBLE USING/CHANGING The actual parameter category must match the formal parameter category. This means
that if a parameter is passed as a USING, it shoud be received as a USING.
INCOMPLETE ACCESS TO
INTERNAL TABLE
Avoid Indirect Index Access to an Internal Table. All INSERT statements need to be either
placed within a LOOP or use a specific row INDEX. Duplicate records for an unique
internal table index will cause a program dump. For all internal table operations make
sure the system is clearly able to identify the internal table row where the change, delete
or insert needs to occur.
INCOMPLETE OR MISSING WHERE
CONDITION
Use a WHERE condition with appropriate indexes where possible.

CONFIDENTIAL
INCORRECT MESSAGE
PARAMETERS
WITH fields must match placeholders defined for the MESSAGE statement.
INCORRECT USE OF FOR ALL
ENTRIES
When using the addition FOR ALL ENTRIES in ITAB, the driver table ITAB and table
fields must have the same type and length.
INEFFICIENT COPY (LARGE DATA
OBJECT)
Avoid poor performing assignment of large amounts of data. This is especially critical in
the case of deep structures or large data elements.
INTERNAL TABLES - DELETE
ADJACENT COMPARING
DELETE ADJACENT DUPLICATES should always be explicit by using the COMPARING
clause, even if there is only one field in the ITAB.
INTERNAL TABLES - LOOP AND
ASSIGN
Use LOOP AT ITAB and assign to a field symbol. This technique improves performance
on medium and large ITABs.
INTERNAL TABLES - MODIFY IN
LOOP ASSIGN
When using LOOPAT … ASSIGNING, MODIFY and UPDATE statements are redundant.
The Assigning is a pointer. Any changes to the row become explicit on the row being
processed so there is no need to issue the update or Modify commands.
INTERNAL TABLES - NESTED
LOOPS
Nested Loops can cause inefficient processing when programmed incorrectly. Use
parallel cursor technique for nested loops with standard tables. It is the most efficient
means of processing Nested Loops. The performance gains are significant.
INTERNAL TABLES - SINGLE READ DO NOT LOOP an itab to retrieve a specific record when a single READ will do the job.
INTERNAL TABLES
- TRANSPORTING
Use the TRANSPORTING clause with READ and MODIFY wherever possible to transport
only the fields necessary.
INTERNAL TABLES SORT BY
BREAK LEVEL FIELDS
FOR BREAK LEVEL processing with the AT command inside a LOOP at ITAB, sort by the
break level fields before entering the LOOP.
INTERNAL TABLES SORTING When sorting internal tables, always be explicit by using "SORT BY key1 … keyn", never
just "SORT" on its own.
INTERNAL TABLES WITH HEADER Avoid any syntax that results in obsolete tables with headers such as OCCURS 0 or With
Header Line or Perform Tables.
INTERNAL TABLES WITH HEADER
IN FORM
Do not use TABLES statement when passing internal tables to FORMS. This will result
in an internal table with Header being created local to the form. ITABS with header are
obsolete.
INTERRUPT COMMANDS RETURN Statement should be used to exit a procedure (FORM, FMOD, METHOD).
EXIT should not be used.
If a conditional statement (i.e LOOP, IF, etc. ) is in the procedure, the programmer can
code either EXIT or RETURN depending on the desired exit scenario i.e. is the intent to
leave the conditional block or to exit the procedure

CONFIDENTIAL
INVALID PROGRAM TYPE FOR
INCLUDE
Include program type attribute must be correctly set to indicate it is an Include
INVALID SLIN PSEUDOCOMMENT Use valid PSEUDOCOMMENTS as defined by SAP when marking code for inspection
bypass.
INVALID VALUE SPECIFICATION Use valid VALUE specifications for a FIELD.
IS ASSIGNED IS ASSIGNED check should be issued prior to a field symbol assignment in the Read
TABLE statement. If the field symbol is referenced and has not yet been assigned, a
short dump will occur.
ITAB MODIFY INDEX IN LOOP Avoid LOOPat ITAB and then modifying by index in the loop.This can lead to unpredictable
results and performance costs.
Avoid inserting new lines while looping over an internal table. Instead, add new lines
inside the LOOP using the APPEND statement to add the new line at the end of the
internal table.
ITAB OVERWRITE IN LOOP During LOOP Processing of an internal table, do not delete or overwrite the table that is
being Looped.
KEY NOT SPECIFIED IN A
BUFFERED TABLE
Use keys in tables to avoid bypassing the buffered table. In the case of Generically
Buffered Key Area, specify all keys that are part of the generic buffered area as defined
in the technical setting of the table.
LIST PROCESSING EVENTS List Processing Event Blocks are obsolete. All report programming should be performed
using the ALV object model. Therefore, any list processing events that are traditionally
used for controlling lists in classic programming are considered obsolete. This would
include Top-of-Page, End-of-Page, New-Page, at pf . Selection screen events are still
used to support selection screens.
LOGICAL OPERATORS INSTEAD OF
WORDS
Use operators ( >=, <=, =, <>, >, <) rather than the obsolete words GE, LE, EQ, NE, GT,
LT
LOOP IN SELECT/ENDSELECT Avoid LOOP/ENDLOOP blocks within SELECT...ENDSELECT statements. They are
very performance expensive.
MAINTAIN TEXT ELEMENTS TEXT Element is not defined in text pool in the original language.
MESSAGE TRUNCATED Message parameter should not exceed field length specification. SAP only provides a
maximum length of 50 characters for any message parameter (SYST-MSGV1-MSGV4).
Please make sure that all fields and texts that are passed into a message variable are no
longer than 50 characters

CONFIDENTIAL
METHODS FOR MODULARIZATION For Modularization and re-usability, always use methods as your first choice over FORMS
(subroutines) and function Modules. In OO context, FORM...ENDFORM is considered
obsolete.
MISSING CRITICAL PROGRAM
ELEMENT
Critical Program Elements are missing and therefore the program can not compile. (This
includes sub objects such as screens, tables, Includes, forms, parameters, etc.). All
referenced components must exist.
MISSING MANDATORY PARAMETER
IN FUNCTION CALL
All mandatory parameters must be specified when calling a function.
MOVE TO INSTEAD OF WRITE TO Use MOVE TO instead of WRITE TO when possible.
NATIVE SQL Avoid using native SQL to ensure database independence and avoid incompatibilities
between different database tables.
NESTED LOOP Nested loops can cause performance issues. This applies to any form of Nested Loop i.e.
WHILE or DO inside of a Loop or a LOOP inside of WHILE or DO. In the case of a Loop
within a Loop, explore the possibility of using a Parallel cursor technique where checks
are in place to ensure that the inner loop record exists using READ and uses EXIT to exit
inner loop when keys are different. With large tables, the performance gains are
significant.
NO READ ACCESS TO FIELD Validate that the FIELDS are used in the program. It is posible that it is referenced
indirectly such as parameter passing to a procdure. If the field is not used anywhere,
remove unreferenced fields from the program.
NO WHERE CONDITION IN A LARGE
TABLE
Where statements should always include index fields for performance reasons, especially
for LARGE tables.
OBJECT UNREFERENCED OR
UNUSED
Remove all program elements that are unused or unreferenced.
OBSOLETE ABAP Avoid the use of obsolete ABAP statements.
OFFSETS AND SUBSCRIPTING Avoid code that uses specific offsets for the purpose of subscripting into parts of a
structure. Offset coding is problematic when coding in a UNICODE environment since
characters are not represented by a single byte and can therefore lead to incorrect data
sub stringing. Offset coding is also very problematic when dealing with dates where
users are able to change their date format.

CONFIDENTIAL
ON CHANGE OF IN LOOPS Avoid using ON CHANGE OF statement for Break level processing. Unpredictable results
can occur with ON CHANGE OF because it is specific to a single field whereas the AT...
ENDAT triggers a break when any change occurs in the field specified or fields left of the
specified field.
OPEN DATASET with ENCODING The ENCODING option determines the character representation of the content of the file.
At minimum, you must specify the encoding option DEFAULT or UTF-8.
When Opening a Dataset for Output in Text Mode, the file should be Opened with the
Encoding Option UTF-8 and With Byte Order Mark(BOM). This will create a proper
Unicode non platform dependant file with a BOM, consisting of 3 bytes at the beginning
of the file that identifes the file as UTF-8
When opening a Unicode File (UTF-8) for Input, specify the addition SKIPPING BYTE-
ORDER MARK so that the BOM is skipped and NOT considered part of the file content.
The file pointer will be set immediately after the 3 byte BOM
OPEN DATASET with MESSAGE Authorization and permission access at the OS level is one of the most frequent causes
of an OPEN statement failing. Always Use the Message clause on the OPEN statement
to trap operating system errors. This approach traps the Operating System error and
therefore goes beyond the standard subrc checking. Subrc only tells if the operation was
successful but does not give the speicfic reason why the operation failed. The Message
Clause reports specific application server errors such as permissions, file existence,
etc.
OUTPUT POSITION 0 NOT
ALLOWED
Avoid using output position 0.
OVER RIDE VIOLATIONS Used to bypass detected rule violations due to technical reasons
PARAMETER PASSING BY
REFERENCE
As a general rule, PASS BY REFERENCE should be used where possible for performance
reasons. This test examines whether it is possible to improve the performance of a
parameter transfer for a method, form, function module, or event. However, there are
programmatic reasons for using by VALUE. i.e. in the case of a RETURNING parameters,
it is always by VALUE. Specifically, the test checks for the following situations:
• The type of the VALUE parameter contains tables whose row type in turn contains
internal tables.
• The type of the VALUE parameter contains tables with different row types.
• The type of the VALUE parameter contains strings, but no tables.
• The parameter type is a flat field with a length > 100 bytes/characters.
• The type of the VALUE input parameter is a flat field with a length <= the parameter
PARAMETER PASSING IN FORMS Define USING parameters by VALUE. Define CHANGING and Internal Tables by
REFERENCE.

CONFIDENTIAL
PARAMETER UNTYPED All parameters must be typed to enable static type checks. If a type cannot be declared,
use the type ANY.
PARAMETERS - USING DOES NOT
MATCH CHANGING
USING parameters must match CHANGING parameters.
POSSIBLE LOSS OF DB CURSOR The database cursor may be lost as a result of certain call sequences that contain
COMMIT. For example, a Commit work or PERFORM inside a SELECT…ENDSELECT
is problematic.
POSSIBLE SEQUENTIAL ACCESS
ON AN INTERNAL TABLE
Avoid sequential access on internal tables. On large tables, this can be costly.Asequential
access will happen if internal tables have incomplete keys or in the case of standard
tables, Binary Search clause is missing. For internal tables avoid using the obsolete
version of READ TABLE ... WITH KEY. Instead specify an appropriate UNIQUE or NON-
UNIQUE INDEX as part of the internal type definition and use READ TABLE ... WITH
TABLE KEY. Note: The addition BINARY SEARCH is still required to avoid sequential
reads when using STANDARD tables.
This rule also applies to change or delete access in internal tables, e.g. deleting data in
an internal table with a WHERE condition results in a full scan of the internal standard
table. A better solution is to define the table as a SORTED table with a nonunique (or
unique) key. In the DELETE statement use the WHERE condition in combination with
WITH TABLE KEY and the key fields. Now the access will be able to leverage the sort
sequence.
PRIMARY KEY FIELDS NOT FULLY
SPECIFIED
Always specify the fields of a primary key in a single record buffered table.
PROBLEM WITH INDEX ACCESS TO
INTERNAL TABLE
When using Non-Numeric Index Value to delete rows from an internal table, use the
format 'DELETE ITAB FROM work areas'
RAISE FOR EXCEPTION MISSING An EXCEPTION that is part of the exception group never gets raised. This exception
should be removed from the exception group if it is never used.
RAISE ONLY IN FUNCTION GROUPS RAISE statements should only be used in FUNCTION groups.
SECONDARY INDEX IN A CLIENT
SPECIFIC TABLE WITHOUT CLIENT
FIELD
Secondary indexes for CLIENT SPECIFIC tables should have client as the first field of
the secondary index.

CONFIDENTIAL
SELECT FOR ALL ENTRIES When using "Select... For all Entries" the following rules MUST be followed:
• Check to make sure driver ITAB is not empty
• Always SORT the ITAB (driver table) by keys.
• Specify all keys used in the WHERE clause.
• DELETE Adjacent Duplicates Comparing the keys that were sorted.
• All Primary Key Fields must be in the Select List.
• The WHERE clause must include INDEX fields to make use of index scan.
• If index fields are not available as part of the WHERE clause, then it is better not to use
FOR ALL ENTRIES. The better option would be a SELECT…WHERE into an ITAB.
Any further filtering can be done using ABAP Memory
SELECT INTO CORRESPONDING Avoid the use of SELECT ... INTO CORRESPONDING especially for tables with a large
number of fields. The CORRESPONDING clause results in DB overhead. The
corresponding target fields are not know until runtime and therefore need to be rebuilt at
execution. The has a negative effect on performance.
Instead, Specify the individual fields required and define the work area to correspond to
the fields being selected.
SELECT SINGLE EXPECTED FOR
SINGLE RECORD BUFFERED
TABLE
Use SELECT SINGLE with full key when accessing Single Record Buffered Table or
buffer will be bypassed.
SELECT WITH A SUBSEQUENT
CHECK
Avoid the use of CHECK statements after a SELECT. Instead use a WHERE statement
to filter the data.
SELECT WITH AGGREGATE
FUNCTION ON BUFFERED TABLE
Use aggregate functions with caution in a buffered table. Aggregate functions will cause
the buffer to be bypassed which leads to increased processing to retrieve data from DB
instead of buffer.
SELECTION SCREEN FIELDS The purpose of a selection screen is to provide the user with flexible options to enter
values that will influence the outcome of the program execution. Create variants, where
possible, and have the user community use the variant to set screen default values.
Exceptions to this rule are non-business technical related parameters i.e. Logical File
Names, etc.
SELECTION TEXT NOT MAINTAINED Be sure to maintain the Selection text for all selection fields and parameters. In multilingual
systems the DDIC reference flag should be set wherever possible to leverage existing
SAP translations from Data Dictionary ==> Reduces translation efforts
SELECTION TEXT WITHOUT
SELECTION FIELD
Selection Texts that are defined but not used or referenced on a selection screen should
be removed from the text element list.

CONFIDENTIAL
SINGLE PERIOD LINE Eliminate lines of code that contain a single period.
STANDARD INTERNAL TABLE
PROCESSING
When Processing a Standard Internal Table:
• Always use the Binary Search option i.e. READ ITAB with KEY Binary Search.
• READ the Internal Table by Keys
• Be sure that table is sorted by same key that is used in the READ WITH KEY statement
(or data will be missed)
STATEMENT UNREACHABLE Unreachable statements have been detected. i.e. after Jump statement such as RAISE:
EXIT. Ensure that all statements can be reached.
STRUCTURES OBSOLETE Use type statement to build local structures. Structure statement is obsolete.
SUPPRESSED RULE SUPPRESSED RULE
SUSPICIOUS ERROR NEEDS FURTHER INVESTIGATION
SYSTEM CALL Never make calls directly to System Functions for production programs. System Calls
and functions are reserved exclusively for SAP™ use.
SYSTEM FIELDS FLAGGED
OBSOLETE
Never Use obsolete system fields. Check Dictionary structure SYST. The data element
description indicates which fields are flagged as obsolete.
SYSTEM FIELDS PASSING &
UPDATING
Never update system fields or pass system fields to Procedures (FORMS, METHODS,
Function Calls). There are some syst fields that are exempt: SY-LSIND,
SY-SUBRC NOT HANDLED Always Check Return Code SY-SUBRC after critical operations – SQL, ITAB Operations,
Function Calls, etc.
TEXT ELEMENT IN POOL NOT USED TEXT ELEMENT from text pool in program is not used.
TEXT ELEMENT INCONSISTENT Text Element is defined differently in the program and the text pool
TEXT ELEMENT MISSING Char. strings without text elements cannot be translated in a multi-lingual environment.
TEXT LITERAL SHOULD BE
NUMERIC
It is more efficient to use numeric literals directly. Text literal must be converted to a
numeric literal.
TRANSPORTING NO FIELDS It does not make sense to use TRANSPORTING NO FIELDS if the fields need to be
referenced
UNCOMPILABLE CODE Use the Code Inspector to eliminate all SYNTAX errors, including syntax warnings.
UNDEFINED INTO FIELD Into LISTS must be of the form (f1...fn) with all fields defined.
UNDEFINED TITLE TITLEBARS should have a title defined.

CONFIDENTIAL
UNDESIRABLE LANGUAGE
ELEMENTS
A number of ABAP statements are no longer compatible with the latest SAP technologies.
These statements still work in a SAP GUI transaction environment but have been replaced
by newer much more efficient and flexible solutions. Programming syntax that is
considered problematic are as follows:
• ABAP list processing statements like WRITE, FORMAT, SKIP, NEW-LINE etc. in
programs should instead using ABAP List Viewer classes for list display functions.
• The use of CALL TRANSACTION USING to submit a BDC. This technology relies on
screen layouts. If a screen layout changes, the code stops working. This makes the
code highly unreliable during the application of Support Packs, Enhancement Packs
and Upgrades. Therefore programs need to use BAPIs to submit business functions.
• Submitting database operations directly from ABAP by calling database functions
directly (e.g. 'DB_COMMIT"). Any use of these functions introduces a high risk of
transaction inconsistencies and needs to be avoided. Similarly, programs need to
avoid direct access to data dictionary function modules changing the databse tables,
e.g. DD_CREATE_TABLE.
• Programs need to avoid using position operations in sequential files. If necessary files
should be processed sequentially instead of controlling the read position (SET
DATASET, GET DATASET, TRUNCATE DATASET).
• Database SELECTs need to avoid retrieving a single line for Update. This operation
includes an implicit database lock quickly leading to bottenecks and deadlocks. Instead
use ENQUEUE functions to lock an object in SAP, read it and subsequently update it.
• Avoid using SELECT .. BYPASSING BUFFER.. since this access avoids using the
database cache causing performance issues and inconsistencies.
• Avoid using native SQL to ensure database independence and avoid incompatibilities
between different database tables.
UNICODE FLAG NOT SET All programs in a Unicode system must have the UNICODE flag set ON. If the flag is not
set in a Unicode system the program dumps with a syntax error. The Unicode flag can
only be set once the program passes the Unicode syntax check (transaction UCCHECK).
In a non-Unicode system the flag does not have to be set, but as of ERP 6.0 SAP only
supports single code page non-Unicode ERP system. Any multi code page system has
to be Unicode. Therefore it's generally better to always turn this flag on
UNIT CLAUSE When outputting numbers that are tied to units of measure, always use the UNIT
formatting option. This will set the number of decimals according to the unit of measure
being output.
UPDATING and PASSING GLOBAL
FIELDS
Avoid the declaration of global variables as much as possible. Avoid passsing Globals to
Subroutines and Methods.
Avoid setting global variables in too many places. A preferred approach to setting globals
is to use dedicated recognized methods that follows best practice naming convention
such as SET_*

www.codeExcellence.com
Tel: (403) 875-0809
info@codeexcellence.com
support@codeExcellence.com
Headquarters in Calgary, Alberta, Canada
CONFIDENTIAL
USER SPECIFIC CONTROL Avoid using references to specific USERS or USERIDs for any reason.
VALUE ASSIGNMENT EXCEEDS
LENGTH
VALUE specifications must not exceed the length of the defined field or type.
VARIABLE NAME INCORRECT Variable names should not begin with %_*. Prefix %_* is reserved for internal names.

Z abap coding_standards_v2_0_t

More Related Content

What's hot

Viewers also liked

Similar to Z abap coding_standards_v2_0_t

More from Rasika Jayawardana

Recently uploaded

Z abap coding_standards_v2_0_t