Вы находитесь на странице: 1из 18

Code Review Checklist

Internal

Note:
This category covers all information that is for internal consumption only. Employees may use such information
in the course of their daily work but may not disclose/impart such data outside of the company without prior
written consent of a Company Authority.

Document Objective
This document is used during Code review to check the adherence of all the checkpoints listed in the document and to record the defects
arising out of code review.

Guidelines:

1. Defect Severity Definitions


H - High severity defect (System crash / Incorrect data which impacts other regions / etc.)
M - Medium severity defect (Execution can continue / Incorrect data which does not impact other regions / etc.)
L - Low severity defect (Aesthetics / Message wording / Menu options / Wrong alarms / Help problems / etc.)

2. Defect Type Definitions


Syntax Assignment Interface Checking Function Data System Documentation
Syntax : Any Code Semantics / Syntax related Defects Function : Missing / Wrong Function calls
Assignment : Incorrect/ Missing assignment to a Variable Data : Incorrect data types or wrong data
Interface : Wrong Interface calls,Missing / Erroneous Interfaces System : Wrong usage of system commands
Checking : Incorrect or Missing checks / validation Documentation : Improper Identation / Inadequate comments / Poor readability of code
3. Defect Cause Definitions
COMM: Communication Failure (incorrect information / lost information /f ailed to communicate a change in information/ Erroneous or inadequate requirements or inputs
specified)
OVER: Oversight (overlooked or forgot something / failed to consider all cases and conditions / Missed Requirements
EDUC: Lack of Education (did not understand the new functionality added / did not understand some aspect of existing system / did not understand programming
language or tool, etc./ Mis-interpretation or Mis-understanding of functionality),Lack of Awareness
TRAN: Transcription Error ( transcribed or copied something incorrectly / knew what to do but just made a mistake)
PROC: Process Problem ( Gap in the process caused the defect) or lack of Standard

Status 3: The status of the defect shall be Open or Closed


Defect Category
(Peer/SQA) 4 Mention whether the defect is out of Peer or SQA
Code Review Checklist
Project ID : Project Title :
Author : Module ID / Sub Module ID : Program ID :
Program Size (in LOC) : Language : Effort Spent (In Person
(If applicable)
Reviewed by : Review Start Date : Hours):
Review End Date:
Inputs for review (Yes/No) Remarks
Are all the reference documents used for Coding available? Yes
Are all the reference documents reviewed and approved (wherever applicable)?
Yes
Is the extended program check done for the code and verified ? Yes
Program Attributes Checkpoints (Yes/No) Remarks
Title : Is the Title a concise description ? Yes
Type :Is the type of program specified correctly ? Yes
Status:Has the status been set following the project standards ? Yes
Application :Has The ABAP application been set following the project standards ?
Yes
Authorization Group :Has the appropriate authorization group been used
following the project standards ? Yes
Package : Has the appropriate package/development class been used following
the project standards ? Yes
Transport Request:Has an appropriate project standard for creating and
associating tasks to transport requests been used ? Yes
Technical settings (F7) : Are the appropriate technical settings used ?
- Data class (USER or USER1 is to be used when creating new customer tables)
- Size Category
- Buffering

Logical Database :Has the appropriate logical database been used following the
project standards ?
Documentation Checkpoints Remarks
Code Comments : Are there adequate comments for ease of maintenance and
reliability ? Yes
Change History: Has a chronological history of modifications maintained following
the project standards ? Yes
Indentation : Is proper identation done using pretty printer ? Yes
Naming Convention Checkpoints (Yes/No) Remarks
Have the Naming Standards of the project been followed ? (For the
applicable constructs) Yes
< Expand The selection to check the constructs >
NA
Table Name : Does it follow a standard naming convention ? (ABxxxxxxxx).
Yes
Constants
Check whether Value of constants are not used as part of either its name or its
comment.
Example: C_VA01 = 'VA01'.
All constants has a functional sense Yes
Programming Convention Checkpoints Remarks
Hardcoding :Are Constants used instead of hardcoding ? If the project has a table
to maintain hardcoding then is this table used ? Is Hard Coding avoided in BDC or
Call Transactions ? Yes
Messages :Is long text used for extended help ? Yes
Are all unused variables , Unused data declaration and other unused program
parts are removed from the program ? Yes
Variables :Is LIKE used over TYPE based on the Version ? Yes
Event Structure:Has the standard structure for ABAP report coding been followed
as outlined in the Programming Standards documentation? Yes
Is SY-SUBRC :Checked to ensure proper inputs when dealing with tables (for
example: READ TABLE, SELECT, INSERT) ? Yes
WHEN OTHERS with CASE : Do all CASE statements have WHEN OTHERS to
capture unexpected errors ? Yes
Are CHECK / EXIT Commands avoided ? Yes
Message Class and Messages : Is the message class defined and used either in
the report line or in the MESSAGE statement depending on the project standards ?
(i.e. Messages are not created of just ‘&&&&’) Yes
Text Elements : Does each ABAP have associated text elements and selection
texts from the source code placed within the Text Elements section ?Are text
elements used for longer text since it provides possibility for multi-language support
? Yes
Modularization Checkpoints (Yes/No) Remarks
Is the code broken into logical segments for modularization into
subroutines/functions/packages whenever possible ? Yes
Are formal parameters passed between modular units such as performs or
functions ? Yes
Is the code executed more than once placed in a form routine ? Is modularity
ensured while coding ? Yes
SQL Queries Checkpoints (Yes/No) Remarks
Is SELECT INTO preferred Over SELECT APPEND ENDSELECT ?
When an internal table needs to be created directly from one database table, the
SELECT INTO is used to fill the internal table. It is faster to use the INTO TABLE
version of a SELECT statement than to use APPEND statements
Yes
Is INTO CORRESPONDING FIELDS avoided ?
Instead is the movement of fields by the position in the SELECT clause ensured ? Yes
For Transparent or POOL tables, is the SELECT statement fully qualified with the
WHERE option including data fields that are not part of the key ? Yes
For Cluster tables, Are only the fields that are part of the key qualified in the
WHERE option ? Is The CHECK command used to eliminate other records ? Yes
Does the ordering of the WHERE statements match the arrangement of the keys in
the table records ? Yes
Do the Fields compared in the WHERE clause of SELECT statements have similar
types ? Yes
Is the use of negative logic in SELECTs avoided ? Yes
Is the Primary Key Used ?Is the full table key specified and SELECT SINGLE
specified? Yes
Secondary Index Usage :
In the WHERE clause do the fields of the INDEX are in the specified order and
linked by the logical AND with comparisons for equality ?
Yes
Are Nested Selects or Loops avoided through the use of dictionary VIEW or by
using FOR ALL ENTRIES appendage to the SELECT statement ? Yes
Are the DB Statement avoided within Loops ? Yes
Is a non-blank / non-empty internal table ensured prior to the command FOR ALL
ENTRIES ? Yes
Column Selection: Does the SELECT statements only query the necessary
columns from a table ? Is SELECT * only used when more than one-third of the
columns are being used ? Yes
UP TO N ROWS: Is the UPTO 1 ROWS appendage added when the full key is
unknown ?
Yes
Sorting :Is SORT ITAB used over SELECT ITAB ORDER BY ?
Yes
Aggregates : For aggregates ( maximum, minimum sum, average,count) is a
SELECT list with aggregate function used over programming the code ?
Yes
Internal Tables Checkpoints (Yes/No) Remarks
Nested Loops: Are nested loops avoided ? If unavoidable, is parallel cursor
technique utilized or wherever possible is a View used ? Yes
Is LOOP…WHERE used instead of LOOP/CHECK ? Yes
Are the key fields specified for READ access explicitly ? Yes
When a minimal number of fields within an internal table record are being modified,
Does it use the "transporting" clause, to reduce the amount of data transfer ?
Yes
When performing BINARY search, Is the internal table first sorted by the key ? Yes
When performing direct reads, Is the BINARY SEARCH used only when the table
contains more than 500 rows ? Yes
REFRESH : Are Internal tables refreshed before using, not only at the beginning
of the program but also just before they are used within a modular unit ? Yes

OCCURS:Is a number other than zero only specified for the OCCURS parameter if
the required storage is less than 8 kilobytes ? yes
SORT Checkpoints (Yes/No) Remarks
Are all SORT statements qualified with the BY option and limited to the fields that
must be used to satisfy processing requirement ? yes
Are the sort fields specified while sorting internal tables? yes
General Optimization Checkpoints (Yes/No) Remarks
Are large tables such as CDHDR, CDPOS, BSEG, MSEG, MKPF, BKPF, VBFA
avoided ? NA
Are selection screen entries validated right away when applicable ? yes
Are DATA statements defined locally for local variables ? yes
Is TYPE I used for counter or loop index ? yes
Are type conversions avoided ? yes
Is the table type considered when constructing the SELECT statement ? yes
Are the existing AND and OR statements within the WHERE clause, replaced by
> and < statements ? yes
Do SELECT statements use as much of the primary key as possible (TRANSP and
POOL tables) ? yes
Do large selects exist that do not match any index ? Is an index usage always
being ensured ? yes
Do select statements exist which causes index fields to be skipped? For Example
multiple selects on the same table. yes
Are there any unnecessary select statements and accessing the same data more
than once avoided ? Are selecting unsued data that are filtered out later avoided? yes
Does Optimized SELECT Statement, array fetches into an internal table ? yes
Are Long SELECTs within the AT SELECTION-SCREEN event avoided? yes
MOVE : Are the destination operands kept as the same data type as the source
operands wherever possible ? yes
Are all LOOPs, IFs, CASEs, and similar statements broken down to their simplest
form and Is the nesting uncomplicated unless absolutely necessary ? yes
Is the sort done before using any AT statement ? yes
Is AT used instead of ON CHANGE OF ? yes
Is CASE used over IF ? yes
IF/CASE :Is the most likely elimination criterion specified first when using the AND
or OR operator ? yes
Is WHILE Preferred over DO ? yes
Is CLEAR field used to initialize rather than explicit moves ? yes

Are Table headers,Work areas and Variables CLEAR at the end of loop process ? yes
Is MOVE CORRESPONDING used for small tables or tables where most, but not
all, fields need to be moved ? yes
Is the table MOVEd as a group when all the fields need to be moved and the
attributes for every field and position are identical ? yes
COLLECT
Is the collect Statement used when possible instead of doing addition in
ABAP code ? Is the preferred construct used for COLLECT command ? NA
Remarks

Remarks

Remarks

Remarks
Remarks

Remarks

Remarks
Remarks

Remarks

Remarks
Code Review Checklist
Project ID : Project Title :
Author : Module ID / Sub Program ID :
Program Size (in LOC) : Module
LanguageID : : Effort Spent (In
(If applicable) Person Hours):
Reviewed by : Review Start Date Review End Date:
:
Defect No. Location Defect Category Severity 1 Type 2 Cause 3 Defect Description Status 4

(Line No.) (Peer/SQA) 5

Ready for Testing (Yes or No)

Sign-off:
Prepared by: <Name > <Sign> <Date>
Reviewed by: <Name > <Sign> <Date>
Audited by: <Name > <Sign> <Date>
Approved by: <Name > <Sign> <Date>
Defect Summary
Severity High Medium Low Total
0 0 0 0
Type Syntax Assignment Interface Function Data System Documentation
0 0 0 0 0 0 0
Cause COMM OVER EDUC TRAN PROC
0 0 0 0 0
Guidelines

1. Defect Severity Definitions


H - High severity defect (System crash / Incorrect data which impacts other regions / etc.)
M - Medium severity defect (Execution can continue / Incorrect data which does not impact other regions / etc.)
L - Low severity defect (Aesthetics / Message wording / Menu options / Wrong alarms / Help problems / etc.)

2. Defect Type Definitions


Syntax Assignment Interface Checking Function Data System Documentation
Refer Cover Sheet for more details

3. Defect Cause Definitions


COMM: Communication Failure (incorrect information / lost information /f ailed to communicate a change in information)
OVER: Oversight (overlooked or forgot something / failed to consider all cases and conditions)
EDUC: Lack of Education (did not understand the new functionality added / did not understand some aspect of existing system / did not understand programming language or tool, etc.)
TRAN: Transcription Error ( transcribed or copied something incorrectly / knew what to do but just made a mistake)
PROC: Process Problem ( Gap in the process caused the defect) or lack of Standard
Status 3: The status of the defect shall be Open or Closed
Defect
Category
(Peer/SQA) 4 Mention whether the defect is out of Peer or SQA
Cause Decription
Total
0
language or tool, etc.)

Вам также может понравиться