SAP Development Code Review Checklist

Developer: Mrudula Yerragudi - GM Austin

Code Review Date: May 2, 2014
Reviewer: Tuncay Karaca - GM Austin
Tech Design Doc ID: G14-EH-0015-ITD-P-825
Transport(s) Reviewed: CE0K905836, CE0K906204

Pass
Yes No
All Objects
CODING CONVENTIONS
Correct change log template used at the beginning of
all created/changed objects. X
Documentation completed for every object (TDD, etc).

Pretty Printer properly completed using correct settings.

X
Use of text elements and constants - no hard coding.
X
Use text elements for all text.(It provides possibility for
multi-language support). X
ABAP Code has appropriate/informative
comments throughout. X
Modifications correctly commented within code.
*[ Del/Ins CPRxxxxx
*] Del/Ins CPRxxxxx X
Appropriate authorization checks implemented.
X
Naming conventions followed (See ABAP Programming
Standards).
X
All dead code removed.
X
Use of OS Commands avoided.
X
Statement BREAK-POINT removed in all objects.
X
Proper use of form routines withing code.
1. Code executed more than once.
2. Large code blocks should be broken up. X
Variables are passed correctly between form routines.
Minimize the use of global variables as much as
possible by declaring locally inside sub-routines. X
Global varianbles/select-options/parameters are not
referenced directly in subroutines. All are passed
correctly via USING and CHANGING parameters. X
For subroutines, the TABLES option is not used unless
technically required.
X
Hard coding of values in BDC or Call Transaction
avoided unless specified in FDD.
X
Variables declared within programs have reference of
the corresponding table/structure fields.
X
TYPE (data element) command used while declaring
the fields whenever feasible instead of LIKE.
Remember, the data element name does not always
match the table field name. X
Work-Areas are used instead of header lines. X
Proper table type used to define internal tables
(Standard, Sorted, Hashed, etc). X
For custom tables, table maintenance generator used
for generating table maintenance interface. X
CODING STRUCTURE

SY-SUBRC checked in all possible places.

X
"Try" and "Catch" logic used for raising exceptions to
avoid short-dumps. X
All variables cleared after use, including refreshing
internal tables and freeing field symbols.
X
After the APPEND statement inside a loop, the work
area that has been appended is cleared. X
If data structures match, MOVE instead of MOVE-
CORRESPONDING used.
X
SORT, DELETE ADJACENT DUPLICATES and READ
TABLE t_tab WITH KEY key BINARY SEARCH
properly used. X
For copying internal tables use ‘=’ operator instead of
Looping & Appending. X
SORT inside a LOOP is not used. X
Sort internal table by fields in the correct order, which
are used in a READ TABLE statement using BINARY
SEARCH. If the order of sorting is invalid the BINARY
SEARCH will never work X
Sort fields and Sort Order on the SORT statement
mentioned explicitly (e.g. SORT ITAB BY FLD1 FLD2
ASCENDING).

CASE statement used instead of IF.ELSEIF. ENDIF

when possible.
When coding IF or CASE, testing conditions are nested
so that the most frequently true conditions are
processed first.
All CASE/WHEN statements include WHEN OTHERS
as the last option.

All MESSAGES are relevant and have proper format.

Use of Logical File Paths and File Names (See ABAP
Programming Standards on use of transaction FILE)
Work areas used with LOOP/ENDLOOP
SELECT STATEMENTS
Usage of nested SELECT statements has been
avoided.
Usage of SELECT/ENDSELECT has been
avoided.
PERFORM statements not used inside
SELECT/ENDSELECT.

SELECT SINGLE used when possible.

SELECT against views or FOR ALL ENTRIES IN used

when possible.

Check the internal table in the "FOR ALL ENTRIES"

clause is not blank.

Sort and DELETE ADJACENT DUPLICATES FROM

internal table before selection from database table
using “FOR ALL ENTRIES” statement.

SELECT fields FROM database tables INTO TABLE

t_tab used instead of APPEND statement.

In SELECT statement, only the required fields are

selected in the same order as they reside on the
database table/structure/view.

For selecting single row from a database table,

“SELECT UP to 1 Rows” is used. “SELECT SINGLE” is
used only when full primary key combination is known.

Usage of SELECT * is avoided when possible.

“SELECT INTO TABLE” rather than “SELECT INTO

CORRESPONDING FIELDS OF TABLE” used.
As many primary keys or index fields as possible have
been specified in the WHERE clause to make the
SELECT efficient.

Fields in the WHERE clause are ordered in the same

way as they are in the DDIC definition/index for the
given table being selected from.

Avoid ORDER BY unless ordering by an index.

To process a join, use a view wherever possible instead

of nested SELECT statements. Network load is
considerably less.
Wild cards like ‘A%’ avoided as much as possible.

Fields specified in the WHERE condition with the

critical operators NOT and <> (negative SQL
statements) not used for a search using database
indexes. If possible formulate SQL statements
positively.

Nested Select is not used. Instead “INNER JOIN”

and/or “FOR ALL ENTRIES” is used. FOR ALL
ENTRIES is to be used instead of “LOOP AT itab /
SELECT / ENDLOOP” (FOR ALL ENTRIES retrieves a
unique result set so ensure you retrieve the full key
from the database).

When creating joins over database tables, there should

be an index at least on the inner table for the fields in
the join condition else use “ FOR ALL ENTRIES” select
statement.

Usage of JOIN is limited to a maximum of 2 i.e. not

more than 3 database tables are joined at one time
(records <500K).

Data selected into internal tables.

PERFORMANCE
Extended Program Check (with character literals
checkbox switched on) & Code Inspector used to rectify
all relevant errors and warnings.

Transaction SE30 (ABAP Runtime Analysis) checked to

measure/compare program performance/runtime if
program has multiple inefficient databases selects or
complicated internal table operations.
Transaction ST05 (SQL Trace) used to see what
indices your database accesses are using. Check
these indices against any “where” clause to assure they
are significant. Check other indices for this table and
where you have to change your “where” clause to use
it. Create new indices if necessary, but do not forget to
check the impact by consulting onsite coordinator.

Data has been selected into an internal table, except

when the table will be very large (i.e., when the internal
table will be greater than 500,000 records). Use “Up to
N Rows” when the number of records needed is known.

Select statement within a GET event is not used.

For large internal tables where only some rows are to

be processed, SORT and then the READ TABLE
command is used to set index to first relevant row
before looping from that index. CHECK or IF…EXIT…
ENDIF used as appropriate to exit from the loop. If
possible the following is used:
Read itab into wa_itab BINARY SEARCH
with key = 'xxx'.

if sy-subrc = 0.
Loop at itab into wa_itab from SY-TABIX
where key = 'xxx'.
Endloop.
endif..

Hashed table is used for processing large amount of

data (provided that you access single records only, and
all with a fully specified key).

DELETE or SORT is not used on a hashed table since

it increases memory consumption.

Sorted table is used for range accesses involving table

key or index accesses.
LOOP AT ITAB INTO WORKAREA WHERE K = ‘XXX’
used instead of LOOP AT ITAB INTO WORKAREA /
CHECK ITAB-K = ‘XXX’.
READ TABLE INTO WORKAREA used instead of only
READ TABLE.

Records not deleted inside LOOP – ENDLOOP.

Example:
Do not use:
LOOP AT ITAB WHERE EQUNR = ‘00001011’.
DELETE ITAB.
ENDLOOP.

Use: DELETE ITAB WHERE EQUNR = ‘00001011’.

MODIFY ITAB ... TRANSPORTING f1 f2 ... for single
line, and MODIFY ITAB ... TRANSPORTING f1 f2 ...
WHERE condition used to accelerate the updating of
internal table

Logical databases avoided. If the program uses a

logical database, but does not require all fields
belonging to a certain GET event, always use the
FIELDS addition to reduce the amount of data selected
by the logical database.

Avoid the aggregate (Count, Max, Min) functions in the

database selection.
Use Parallel Cursor methods for nested loop into the
internal tables if second internal table contains
considerable number of records (>500K).
DATABASE UPDATES
If possible, UPDATE/INSERT statement used instead of
MODIFY.

The following steps must be followed during database updates:

Data to be edited is locked.

Current data read from the database.

Data processed and written to the database.

Locks released that were set at the beginning.

WORKFLOWS
The workflow deadlines expire and move to the next
person/agent.
If a task is set to Generic, "Terminate workflow when no
agent found" has been selected.

Agent determination done using positions, not users.

FORMS
All nodes and descriptions renamed to be useful and
logical.

Meaningful folders created for logical units/areas.

Redundant data retrieval avoided where data is
available in interface.

Unless formatting the data output, code lines should

only be used to call FM or an object.

All inactive nodes commented as such.

New Development: preconfigured form used.

(OSS Note 843193)
opment Code Review Checklist
Mrudula Yerragudi - GM Austin
May 2, 2014
Tuncay Karaca - GM Austin
G14-EH-0015-ITD-P-825
CE0K905836, CE0K906204

Comments Remediation
All Objects
CODING CONVENTIONS

TDD will be reviwed.

CODING STRUCTURE
SELECT STATEMENTS
PERFORMANCE
 DATABASE UPDATES

ng steps must be followed during database updates:

WORKFLOWS

FORMS
Question for all IF…ENDIF statements.

Can we need to address all other possibilities too?

At the beginning of subroutine u019, b_result = b_true

After that it might get b_false, but but what about ELSE possibilities. If ELSE possibility happens it will stay as b_true

There is NO ELSE for these:

Also it seems whenever b_result = b_flase occurs, we need to EXIT/RETURN from the subroutine.?
As here:

It seems that u019 subroutine goal is set b_true at the beginning but then look for any b_false then exit.
Paste a screen shot of the extended program check results here and include any comments.
All Errors and Warnings should be corrected prior to approval.
May 2, 2014
Paste a screen shot of the code inspector results here and include any comments.
***Please use variant ZGMC_GB_DEFAULT for the inspection.