Copy of Code Review Checklist v1(1).0

document.xlsx Page 1 of 24

SAP Code and Unit Test Review

Client:

Project:

RICEFW ID:

Description:

Programmer:

Reviewed by:

Date Reviewed:

Rejections Number: ###

Errors Number: ###

Open Critical Errors

OK-0 The criterion is met without further rework

OK-n The criterion is met after n-times rework

FAIL-n The criterion is not met after n-times rework. Some more rework is required

N/A Not Applicable

APPL Applicable

# Critical* Description Status Comments**

General Criteria

REQUIREMENTS

1 Functional Design requirements OK-0 ###

2 Technical Design requirements OK-0 ###

CODE INSPECTIONS

Program Attributes

3 Yes OK-0 ###

4 Yes OK-0 ###

5 No OK-0 ###

6 Yes N/A ###

7 No OK-0 ###

8 Yes OK-0 ###

Documentation

9 Yes ###

16 No OK-0 ###

17 Yes OK-0 ###

18 No OK-0 ###

19 No N/A ###

20 Yes OK-0 ###

21 No OK-0 ###

Naming Standards

Title The title is a concise description

Type The type of program is specified correctly

Application The ABAP application has been set following the project standards

Authorization Group The appropriate authorization group has been used following the project standards

Package The appropriate package has been used following the project standards

Function ModuleFunction module assigned to appropriate function group

Online Program DocumentationThe Online Program Documentation provides functional leads and end users with necessary information to determine report functionality. It also contains information on file inputs and outputs

Program header:- Standard program header (as per the pre-defined skeleton) for all new programs (including Function Modules and all Include programs)

Code CommentsInternal commenting has been made enough to ease program maintenance and reliability of the code.

Change History. HeaderA chronological history of modifications has been set following the project standards.

Change History. DetailAll changes to existing code, function modules and user-exits have appropriate notation on changes. Inserted code is blocked out with the corresponding marks.

CUSTOM TRANSACTIONTransaction Name begins with Y or Z; same as custom ABAP program.Description follows Report short text.Calls Custom ABAP program which must have an Auth. Group associated to it.Object type: Program and selection screen (report transac

CUSTOM TABLES:Name begins with Z.Package.Delivery Class.Environment/Tab.maint.generator. Function group Authorization



Client:

Project:

RICEFW ID:

Description:

Programmer:

Reviewed by:

Date Reviewed:


Errors Number: ###





N/A Not Applicable

APPL Applicable


22 No OK-0 ###

23 No OK-0 ###

Programming Standards

24 No The Programming Standards of the project have been followed OK-0 ###

25 Yes OK-0 ###

26 No ###

27 No OK-0 ###

28 No ###

29 No OK-0 ###

30 Yes OK-0 ###

31 No OK-0 ###

32 No OK-0 ###

33 Yes OK-0 ###

34 Yes OK-0 ###

35 Yes ###

36 No OK-0 ###

The Naming Standards of the project have been followed (some may not apply)Program NameGlobal VariablesStructures or PL/SQL tablesInternal TablesLocal VariablesInput Parameters in a FORM/PERFORMOutput Parameters in a FORM/PERFORMInput/Output Param

ConstantsValue of constants are not used as part of either its name or its comment.Example: C_VA01 = 'VA01'.All constants has a functional sense

HardcodingConstants should be used instead of hardcoding. If the project has a table to maintain hardcoding then this table should be used

MessagesMessages use long text for extended help

CurrencyCurrency calculations are performed between currency fields only

Units of measureCalculations performed on fields with the same unit of measure

UppercaseKeywords in uppercase

All unused variables and program parts are removed from the program

VariablesTYPE preferred to LIKE

Event Structure The standard structure for ABAP report coding has been followed as outlined in the Programming Standards documentation

SY-SUBRC Checked to ensure proper inputs when dealing with tables (for example: READ TABLE, SELECT, INSERT)

WHEN OTHERS with CASEAll CASE statements must have WHEN OTHERS to capture unexpected errors

CHECK / EXIT CommandsThese are dangerous commands and should be avoided, especially within USER-EXITs. These commands act much like a 'goto' statement and are considered overloaded commands (ie, their meaning is dependent on the context of their use)

Message Class The message class to be used is defined either in the report line or in the MESSAGE statement depending on the project standards



Client:

Project:

RICEFW ID:

Description:

Programmer:

Reviewed by:

Date Reviewed:


Errors Number: ###





N/A Not Applicable

APPL Applicable


37 No OK-0 ###

38 No OK-0 ###

39 Yes ###

Modularization

40 No OK-0 ###

41 Yes OK-0 ###

42 No Local variables are used as possible. ###

43 Yes ###

44 Yes ###

SQL Interfaces APPL <- Change value if required

45 Yes OK-0 ###

46 Yes OK-0 ###

WHERE CLAUSE47 Yes N/A ###

48 Yes N/A ###

49 Yes OK-0 ###

50 No OK-0 ###

51 Yes EQ has been specified whenever possible OK-0 ###

52 Yes The use of negative logic in SELECTs is avoided whenever possible OK-0 ###

53 No ###

54 Yes OK-0 ###

Message Class and MessagesMessage Class and Messages used in accordance with project or HCL-Axon standards. (i.e. Messages are not created of just ‘&&&&’)

Text Elements Each ABAP should have associated text elements and selection texts from the source code placed within the Text Elements section

Range TablesFor defining internal tables with the same structure as selection tables, the RANGES statement should be used

Break code into logical segments for modularization into subroutines/functions/packages whenever possible

To pass formal parameters between modular units such as performs or functions

PERFORMCost/Run-time: Factor 1 (Note: this is the base factor for the techniques to follow)

CALL FUNCTIONCost/Run-time: Factor 12

SELECT INTO preferred to 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 u

INTO CORRESPONDING FIELDSThis clause should be avoided, and ensure the movement of fields by the position in the SELECT clause

For Transparent or POOL tables, the SELECT statement is as fully qualified as possible with the WHERE option, including data fields that are not part of the key

For Cluster tables, only the fields that are part of the key are qualified in the WHERE option. The CHECK command is used to eliminate other records

The ordering of the WHERE statements match the arrangement of the keys in the table records

Fields compared in the WHERE clause of SELECT statements have similar types

When using the AND or OR operator the most likely elimination criteria is specified first. (Expressions are evaluated left to right and the evaluation ends when the final result has been established)

Primary Key UsedWhenever possible, the full table key is specified and SELECT SINGLE is specified



Client:

Project:

RICEFW ID:

Description:

Programmer:

Reviewed by:

Date Reviewed:


Errors Number: ###





N/A Not Applicable

APPL Applicable


55 Yes N/A ###

56 Yes OK-0 ###

57 Yes N/A ###

58 Yes OK-0 ###

59 Yes OK-0 ###

60 No N/A ###

61 No ###

Internal Tables APPL <- Change value if required

62 Yes OK-0 ###

63 Yes Unnecessary moves are avoided by using explicit Work Areas OK-0 ###

64 Yes LOOP…WHERE is used instead of LOOP/CHECK ###

65 Yes OK-0 ###

66 Yes N/A ###

67 No ###

72 Yes OK-0 ###

Secondary Index UsageWhen possible, in the WHERE clause the fields of the INDEX are in the specified order and linked by the logical AND with comparisons for equality.A secondary index has been considered if:1. Non-key fields or fields for which inde

Nested Selects or LoopsNested selects and loops are avoided through the use of dictionary VIEW or by using FOR ALL ENTRIES appendage to the SELECT statement

DB Statement within LoopsThere is not any DB statement (SELECT, INSERT, UPDATE, ...) in the scope of a loop

FOR ALL ENTRIESWhen using this command, make sure that the table is not empty first

Column SelectionSELECT statements only query the necessary columns from a table. SELECT * is only used when more than one-third of the columns are being used

UP TO N ROWS:When a full key is unknown and only one record is needed, the UP TO 1 ROWS appendage is added to the SELECT statementPreferred: SELECT FIELD1 FROM TABLE UP TO 1 ROWS. ENDSELECT.Avoid: SELECT FIELD1 FROM TABLE. EXIT.

AggregatesWhen finding aggregates such as maximum, minimum sum, average, and count, a SELECT list with the aggregate function is used instead of programming the code

Nested LoopsNested loops are avoided. If unavoidable, take advantage of parallel cursor technique

For READ operations, the key fields are specified for READ access explicitly

When performing BINARY search, the internal table must be first sorted by the key

When performing direct reads, the BINARY SEARCH is used only when the table contains more than 500 rows

CLEARClear the header line of the internal table After ‘DELETE’Clear the header line before ENDLOOPCLEAR the internal table header line after APPEND



Client:

Project:

RICEFW ID:

Description:

Programmer:

Reviewed by:

Date Reviewed:


Errors Number: ###





N/A Not Applicable

APPL Applicable


73 Yes OK-0 ###

74 Yes N/A ###

75 No Preferably LOOP AT itab ASSIGNING <field symbol> is used N/A ###

76 No Use Modify Internal table TRANSPORTING f1….fn as far as possible N/A ###

77 No Append to be used instead of Collect OK-0 ###

78 No OK-0 ###

SORT79 Yes OK-0 ###

General Optimization

80 No OK-0 ###

81 Yes Perform SE30 on program ###

82 Yes Perform ST05 to analyze SQL statements ###

83 Yes Run transaction SCI. ###

84 No OK-0 ###

85 Yes OK-0 ###

86 Yes OK-0 ###

86 Yes Authority-checks available where needed / requested N/A ###

87 Yes Validate selection screen entries right away when applicable OK-0 ###

88 No OK-0 ###

89 Use IS/IS NOT INITIAL instead of hard coded comparisons OK-0 ###

90 Global data declared in one place OK-0 ###

91 Variables and constants declarations should be documented OK-0 ###

92 Top Include used OK-0 ###

93 ###

94 OK-0 ###

95 OK-0 ###

96 DATA statements defined locally for local variables OK-0 ###

97 Use TYPEs for defining duplicate structures OK-0 ###

98 Set up an internal field with the VALUE option ###

99 Use TYPE I for counter or loop index OK-0 ###

REFRESHInternal tables are refreshed before using, not only at the beginning of the program. It is preferred to refresh just before they are used within a modular unit

FREEThe FREE command is used to release the memory allocated to internal tables when the program is finished processing the data in the table and when the following conditions exist:1. The internal table is large2. The internal table is sorted and repr

OCCURSA number other than zero is only specified for the OCCURS parameter if the required storage is less than 8 kilobytes

All SORT statements are qualified with the BY option and limited to the fields that must be used to satisfy processing requirement

Sap Code InspectorWith extended syntax check (SLIN)

Avoid large tables such as CDHDR, CDPOS, BSEG, MSEG, MKPF, BKPF, VBFA

Does the ABAP run with appropriate “no rows selected” criteria and returns immediately?

Does the ABAP run quickly with an appropriate single row expected result?

Selection-screen for the program- Transaction input fields such as the sales order number, purchase order number should not be validated- Appropriate error, warning or information messages should be displayed- Variants should be created and included in

Call transaction identified and described andCall subroutine described

Data declarations as far as possible are declared using like from a DDIC.

Parameter documented as input/output in Perform Statements and Form Statements



Client:

Project:

RICEFW ID:

Description:

Programmer:

Reviewed by:

Date Reviewed:


Errors Number: ###





N/A Not Applicable

APPL Applicable


100 Avoid type conversions OK-0 ###

101 Consider the table type when constructing your SELECT statement OK-0 ###

102 ###

103 Avoid unnecessary accesses into the database select OK-0 ###

104 OK-0 ###

105 Use commit work judiciously N/A ###

106 N/A ###

107 N/A ###

108 N/A ###

109 N/A ###

110 Can these unnecessary select statements be removed? N/A ###

111 Optimized SELECT Statements: array fetches into an internal table OK-0 ###

112 Where possible, avoid accessing the same data more than once OK-0 ###

113 Avoid selecting useless data that are filtered out later N/A ###

114 Long SELECTs within the AT SELECTION-SCREEN event are avoided N/A ###

115 OK-0 ###

116 OK-0 ###

117 AT preferred to ON CHANGE OF N/A ###

118 CASE Preferred to IF OK-0 ###

119 N/A ###

120 WHILE Preferred to DO ###

121 OK-0 ###

MOVE CORRESPONDING122 N/A ###

123 N/A ###

114 N/A ###

Within the WHERE clause, AND and OR statements exist that could be replaced by > and < statements

SELECT statements use as much of the primary key as possible (TRANSP and POOL tables)

Read through a large table processing records in “Blocks” (Array processing with OCCURS and UP TO nn ROWS)

Selection criteria hit on primary keys of large tables (minimizing the search)

Large selects exist that do not match any index. Always ensure an index is being used

Do large selects exist that do not match an index due to “skipping” index fields?

MOVEWhen possible, the destination operands are kept as the same data type as the source operands

All LOOPs, IFs, CASEs, and similar statements are broken down to their simplest form and nesting is not complicated unless absolutely necessary

IF/CASEWhen using the AND or OR operator the most likely elimination criterion is specified first

CLEAR Field for InitializationCLEAR field is used to initialize rather than explicit movesTable headers and work areas are CLEAR at the end of loop process

It's only used for small tables or tables where most, but not all, fields need to be moved

When all fields need to be moved and the attributes for every field and position are identical, the table is MOVEd as a group

If there is any division in the program, then the denominator is checked for zero before division



Client:

Project:

RICEFW ID:

Description:

Programmer:

Reviewed by:

Date Reviewed:


Errors Number: ###





N/A Not Applicable

APPL Applicable


115 N/A ###

116 Forms declared in the order in which they are being used N/A ###

TABLE INSPECTION

Object Attributes N/A <- Change value if required

117 ###

118 ###

119 ###

120 ###

120 ###

121 ###

Maintainability of code

120 Every code paragraph is preceded with proper comment OK-0 ###

121 N/A ###

122 Redundant code should be removed N/A ###

123 ###

124 All comments are in English OK-0 ###

COLLECTWhen COLLECT semantics are needed, the COLLECT command is used.Preferred: SELECT matnr werks lgort umlme FROM mard INTO (v_mard3-matnr, v_mard3-werks v_mard3-lgort, v_mard3-umlme). COLLECT

Table NameFollows standard and naming convention (ABxxxxxxxx).

Short TextThe title is a concise description

Development ClassThe appropriate development class has been used.

Change RequestThe appropriate project standard for creating and associating tasks to change requests has been used.

Tables created should have:- Delivery class ‘A’- Client as the first key (unless client-independent)- Maintenance view created (if to be maintained manually)- Foreign keys should be defined- SAP data elements used where possible- Technical attribute

Technical settings (F7)- Data class (USER or USER1 is to be used when creating new customer tables) - Size Category- Buffering

Every form has the format of SAP standard form documentation and proper comments explaining the purpose and the parameters

Translations to be done in the customer language for the error messages provided



Client:

Project:

RICEFW ID:

Description:

Programmer:

Reviewed by:

Date Reviewed:


Errors Number: ###





N/A Not Applicable

APPL Applicable


125 Text-elements should be used along with hard-coded literal ###

126 OK-0 ###

Documentation

127 Ensure documentation exists OK-0 ###

128 OK-0 ###

Data Naming standards APPL <- Change value if required

129 OK-0 ###

130 OK-0 ###

131 OK-0 ###

Quality

132 OK-0 ###

133 OK-0 ###

134 OK-0 ###

Print Programs N/A <- Change value if required

135 ###

145 Header and footer texts comply with the Standard texts.(if any) ###

136 Code review done for all languages (if any) ###

146 ###

Screen Developments N/A <- Change value if required

147 Screen texts should always be referred to a data element ###

148 Validations on input screen elements done using chain/endchain ###

149 PF Status created as per the spec ###

150 Screen numbers created as per ABAP programming standards ###

Plant activation N/A <- Change value if required

151 Plant activation logic has been incorporated ###

BDC N/A <- Change value if required

152 Input file validation done and error message displayed accordingly ###

158 F4 help given in case user is not entering any filename ###

153 ###

159 Call transaction error messages are captured in an internal table ###

154 Is sy-subrc eq. 0 checked after a transaction? ###

160 Refresh Clear bdcdata done after a call transaction ###

Pretty printer used for fresh developments. No pretty printer used for old enhancements

Documentation for newly created ABAP objects have been done (Eg. User defined tables, structures, etc.).

Field name- Standard abbreviations used- Standard prefixes and suffixes used- Data is grouped logically- Adequate documentation for German fields- Short text exists for each filed name

Data Element- Follows standard and naming convention (ABxxxxxxxx).xxxxxxxx SAP field name if possible

Domain- Follows standard and naming convention (ABxxxxxxxx).xxxxxxxx- Use existing domain names if possible

Y2K-DatesDates are in type DATE

NumbersNumbers are in type NUM or QUAN

MoneyMonetary values are in type CURR

Print Program and Layout set Customized for a given output Type(SPRO maintenance)

Different language layout-set programs are triggered according to customer-language or functional specifications.

Call transaction/BDC_SESSION method used as per the specification



Client:

Project:

RICEFW ID:

Description:

Programmer:

Reviewed by:

Date Reviewed:


Errors Number: ###





N/A Not Applicable

APPL Applicable


155 ###

161 ###

156 ###

162 ###

UNIT TEST PLAN INSPECTION

163 Complete Unit Test Plan with proper Cycles ###

164 ###

165 ###

166 ###

Report Criteria APPL <- Change value if required

167 Yes N/A ###

168 Yes N/A ###

169 Yes OK-0 ###

170 Yes Test all logical variation in data to be reported OK-0 ###

171 Yes Test every calculation OK-0 ###

172 Yes OK-0 ###

173 Yes OK-0 ###

174 Yes Check that every selection criteria is processed correctly OK-0 ###

175 Yes Test logical combinations of selection criteria as appropriate OK-0 ###

176 Yes OK-0 ###

177 Yes OK-0 ###

178 Yes N/A ###

179 Yes OK-0 ###

If BDC_SESSION method is used and if unable to open session using BDC_OPEN appropriate message is given

If BDC_SESSION method is used and if unable to insert using BDC_INSERT appropriate message is given.

If BDC_SESSION method is used and if unable to close session using BDC_CLOSE appropriate message is given

Audit report displaying the records, which have been posted or not is shown. (If required)

Check that all test conditions included in functional design are included in Unit Test Plans

All information is transported to the required clients/systems. In particular, ensure client-dependient data (table contents, forms, etc) is transported to the necessary clients/systems so that tests are propertly carried out.

Test were conducted with HTML GUI in case the end user will use that GUI (not PC GUI).

Test all report and column headings are formatted exactly to report specifications

Test that page headers correspond to data printed for a particular page

All fields need to be verified against transactions and database tables

Verify that the formatting and spacing is identical to the functional design

Verify that all sorts and totals operate as specified in the functional design

Report/Screen standard features:- Line-size, line-count, heading or no-heading, defined according to list output. - Use standard line-sizes of 80,120 or 255 wherever necessary. - Features like navigation, format, color, using Unit/Currency option while

If the program has selection screen, the selection fields must have value help (F4) wherever applicable. Use standard match code objects wherever possible.

Top-of-page event handled for all cases. Report displayed in accordance to it. Ex: - If the report has to display two kinds of headers for two different types of displays.

Correct event flow. The correct order is: - Initialization->At-selection screen->Start-of-selection->end-of-selection->top-of-page



Client:

Project:

RICEFW ID:

Description:

Programmer:

Reviewed by:

Date Reviewed:


Errors Number: ###





N/A Not Applicable

APPL Applicable


180 Yes OK-0 ###

181 Yes OK-0 ###

182 Yes OK-0 ###

183 Yes If required, data is initialized in initialization event. OK-0 ###

Interface & Conversion Criteria APPL <- Change value if required

184 Yes Test that data being processed are in the proper format OK-0 ###

185 Yes OK-1 ###

186 Yes OK-1 ###

187 Yes OK-0 ###

188 Yes Check that data was committed to database tables properly OK-0 ###

189 Yes OK-0 ###

190 Yes OK-0 ###

191 Yes OK-0 ###

192 Yes OK-0 ###

193 Yes OK-0 ###

194 Yes OK-0 ###

195 Yes Test that data are exported in the correct format and sequence OK-0 ###

196 Yes OK-0 ###

197 Yes OK-0 ###

198 Yes ###

199 Yes OK-0 ###

200 Yes N/A ###

Start of selection and end of selection events:- Data selection done in start-of-selection- Selected data processed after end-of-selection- Proper error handling done providing adequate error/warning/information messages.- If the error or warning mess

Do not perform database validation at the at-selection screen as far as possible.

List processing:- All Similar Fields are written below correct heading and in columnar format. E.g. ‘WRITE … UNDER’ variant of WRITE statement to be used- Amount fields displayed with currency key, unless specified not- Alignment of fields – Amount, qu

Test every data field through (and SAP display transaction, if applicable) to ensure that it was properly mapped

Test that the data is processed in background versus transactions or BDCs as specified in the functional design

If applicable, test every logical variation in the data to ensure that the screen flow continues as expected

Test that invalid data is recognized and properly reported per the functional specifications

Test that disaster recovery is properly handled per the functional specifications

If applicable, test that the object attributes are the same that in the specified in the technical design

Test that the number of records read are the same that in the input file

Test that the number of records converted are the same that the read one

Verify that the correct data entered is passed to the external system

Verify that the interface handles properly all logical variation in the data

Verify that export fields are of the correct length to handle maximum data lengths

Automatic generation after import option is provided in the interface definition.

Data sets are written into the file with proper length specification (Using the ‘describe table’ command), in order to avoid hard coding of length.

For files names a) Table used to read the relevant file nameb) If no entry found in the table, default file name should be used



Client:

Project:

RICEFW ID:

Description:

Programmer:

Reviewed by:

Date Reviewed:


Errors Number: ###





N/A Not Applicable

APPL Applicable


201 Yes OK-0 ###

Enhancement Criteria N/A <- Change value if required

202 Yes ###

203 Yes ###

204 Yes Test every logical data variation ###

205 Yes ###

206 Yes ###

207 Yes ###

Form Criteria N/A <- Change value if required

208 Yes ###

209 Yes Test any calculations that are made ###

210 Yes ###

211 Yes ###

OK-0 The criterion is met without further reworkOK-n The criterion is met after n-times reworkFAIL-n The criterion is not met after n-times rework. Some more rework is requiredN/A Not ApplicableAPPL Applicable

* Critical checks constitute grounds for code rejection if criteria are not met.** Comments are required when a criterion has not been met.

Error handling:- Proper error handling is done as per the standards. - Errors can either be displayed on the screen or recorded in the protocol, as required. Errors occurring should be re-processable - Inbound interfaces should check for blank records

Test every conceivable scenario in which the enhancement can be executed. Use screen prints with detailed test scripts to clearly document each step in the testing process.

Test cycles with multiple combinations of transactions such as Create, Change, Print, Delete, for a particular data entity

Test logical point at which the enhancement might be called, yet should not be called

Verify that any information entered into the system via the enhancement is properly committed to the database using a combination of standard SAP forms, reports, and display transaction

Validate that when an enhancement framework is ued that there are not BADI's, function exits, etc. available that can be employed.

A condition should be written to verify each field that is brought into the form comes from the appropriate field

Verify that the format and spacing match that of the functional design

Test the maximum length of every field to ensure that proper format is maintained



Client:

Project:

RICEFW ID:

Description:

Programmer:

Reviewed by:

Date Reviewed:


Errors Number: ###





N/A Not Applicable

APPL Applicable


# Criterion Comment on Criterion Status Others

1 ###

2 ###

3 ###

4 ###

5 ###

6 ###

7 ###

8 ###

9 ###

10 ###

11 ###

12 ###

13 ###

14 ###

15 ###

16 ###

17 ###

18 ###

19 ###

20 ###

21 ###

22 ###

23 ###

24 ###

25 ###

26 ###

27 ###

28 ###

29 ###

30 ###

31 ###

32 ###

33 ###

34 ###

35 ###

36 ###

37 ###

38 ###

39 ###

40 ###

41 ###

42 ###

43 ###

44 ###

45 ###



Client:

Project:

RICEFW ID:

Description:

Programmer:

Reviewed by:

Date Reviewed:


Errors Number: ###

Open Critical Errors 0




N/A Not Applicable

APPL Applicable


General Criteria

REQUIREMENTS

1 Functional Design requirements ###

2 Technical Design requirements ###

CODE INSPECTIONS

Program Attributes

3 Yes ###

4 Yes ###

5 No ###

6 Yes ###

7 No ###

8 Yes ###

Documentation

9 Yes ###

16 No ###

17 Yes ###

18 No ###

19 No ###

20 Yes ###

21 No ###

Naming Standards

Title The title is a concise description

Type The type of program is specified correctly

Application The ABAP application has been set following the project standards

Authorization Group The appropriate authorization group has been used following the project standards

Package The appropriate package has been used following the project standards

Function ModuleFunction module assigned to appropriate function group

Online Program DocumentationThe Online Program Documentation provides functional leads and end users with necessary information to determine report functionality. It also contains information on file inputs and outputs

Program header:- Standard program header (as per the pre-defined skeleton) for all new programs (including Function Modules and all Include programs)

Code CommentsInternal commenting has been made enough to ease program maintenance and reliability of the code.

Change History. HeaderA chronological history of modifications has been set following the project standards.

Change History. DetailAll changes to existing code, function modules and user-exits have appropriate notation on changes. Inserted code is blocked out with the corresponding marks.

CUSTOM TRANSACTIONTransaction Name begins with Y or Z; same as custom ABAP program.Description follows Report short text.Calls Custom ABAP program which must have an Auth. Group associated to it.Object type: Program and selection screen (report transaction)

CUSTOM TABLES:Name begins with Z.Package.Delivery Class.Environment/Tab.maint.generator. Function group Authorization



Client:

Project:

RICEFW ID:

Description:

Programmer:

Reviewed by:

Date Reviewed:


Errors Number: ###





N/A Not Applicable

APPL Applicable


22 No ###

23 No ###

Programming Standards

24 No The Programming Standards of the project have been followed ###

25 Yes ###

26 No ###

27 No ###

28 No ###

29 No ###

30 Yes ###

31 No ###

32 No ###

The Naming Standards of the project have been followed (some may not apply)Program NameGlobal VariablesStructures or PL/SQL tablesInternal TablesLocal VariablesInput Parameters in a FORM/PERFORMOutput Parameters in a FORM/PERFORMInput/Output Parameters in a FORM/PERFORMTable Parameters in a FORM/PERFORMStatics used in Subroutines (FORM/PERFORM and FUNCTION)ParametersSelect-OptionsRadio ButtonsCheckboxesPushbuttonsSubscreensCombo BoxesFramesField SymbolsField GroupsRangesLocal Internal TablesTable ControlsTab Strips

ConstantsValue of constants are not used as part of either its name or its comment.Example: C_VA01 = 'VA01'.All constants has a functional sense

HardcodingConstants should be used instead of hardcoding. If the project has a table to maintain hardcoding then this table should be used

MessagesMessages use long text for extended help

CurrencyCurrency calculations are performed between currency fields only

Units of measureCalculations performed on fields with the same unit of measure

UppercaseKeywords in uppercase

All unused variables and program parts are removed from the program

VariablesTYPE preferred to LIKE

Event Structure The standard structure for ABAP report coding has been followed as outlined in the Programming Standards documentation



Client:

Project:

RICEFW ID:

Description:

Programmer:

Reviewed by:

Date Reviewed:


Errors Number: ###





N/A Not Applicable

APPL Applicable


33 Yes ###

34 Yes ###

35 Yes ###

36 No ###

37 No ###

38 No ###

39 Yes ###

Modularization

40 No ###

41 Yes ###

42 No Local variables are used as possible. ###

43 Yes ###

44 Yes ###

SQL Interfaces N/A <- Change value if required

45 Yes ###

46 Yes ###

WHERE CLAUSE47 Yes ###

48 Yes ###

49 Yes ###

50 No ###

SY-SUBRC Checked to ensure proper inputs when dealing with tables (for example: READ TABLE, SELECT, INSERT)

WHEN OTHERS with CASEAll CASE statements must have WHEN OTHERS to capture unexpected errors

CHECK / EXIT CommandsThese are dangerous commands and should be avoided, especially within USER-EXITs. These commands act much like a 'goto' statement and are considered overloaded commands (ie, their meaning is dependent on the context of their use)

Message Class The message class to be used is defined either in the report line or in the MESSAGE statement depending on the project standards

Message Class and MessagesMessage Class and Messages used in accordance with project or HCL-Axon standards. (i.e. Messages are not created of just ‘&&&&’)

Text Elements Each ABAP should have associated text elements and selection texts from the source code placed within the Text Elements section

Range TablesFor defining internal tables with the same structure as selection tables, the RANGES statement should be used

Break code into logical segments for modularization into subroutines/functions/packages whenever possible

To pass formal parameters between modular units such as performs or functions

PERFORMCost/Run-time: Factor 1 (Note: this is the base factor for the techniques to follow)

CALL FUNCTIONCost/Run-time: Factor 12

SELECT INTO preferred to 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

INTO CORRESPONDING FIELDSThis clause should be avoided, and ensure the movement of fields by the position in the SELECT clause

For Transparent or POOL tables, the SELECT statement is as fully qualified as possible with the WHERE option, including data fields that are not part of the key

For Cluster tables, only the fields that are part of the key are qualified in the WHERE option. The CHECK command is used to eliminate other records

The ordering of the WHERE statements match the arrangement of the keys in the table records

Fields compared in the WHERE clause of SELECT statements have similar types



Client:

Project:

RICEFW ID:

Description:

Programmer:

Reviewed by:

Date Reviewed:


Errors Number: ###





N/A Not Applicable

APPL Applicable


51 Yes EQ has been specified whenever possible ###

52 Yes The use of negative logic in SELECTs is avoided whenever possible ###

53 No ###

54 Yes ###

55 Yes ###

56 Yes ###

57 Yes ###

58 Yes ###

59 Yes ###

60 No ###

61 No ###

Internal Tables APPL <- Change value if required

62 Yes ###

When using the AND or OR operator the most likely elimination criteria is specified first. (Expressions are evaluated left to right and the evaluation ends when the final result has been established)

Primary Key UsedWhenever possible, the full table key is specified and SELECT SINGLE is specified

Secondary Index UsageWhen possible, in the WHERE clause the fields of the INDEX are in the specified order and linked by the logical AND with comparisons for equality.A secondary index has been considered if:1. Non-key fields or fields for which index support does not exist are repeatedly used to make selections.2. Only a small part of a large table is selected (<5%).3. The WHERE condition of the SELECT is simple.4. Fields that make up the index significantly reduce the selection set of the records by matching the unique qualifiers in the WHERE clause.Note: prior to creating secondary indexes, consultation with the database administrator is required

Nested Selects or LoopsNested selects and loops are avoided through the use of dictionary VIEW or by using FOR ALL ENTRIES appendage to the SELECT statement

DB Statement within LoopsThere is not any DB statement (SELECT, INSERT, UPDATE, ...) in the scope of a loop

FOR ALL ENTRIESWhen using this command, make sure that the table is not empty first

Column SelectionSELECT statements only query the necessary columns from a table. SELECT * is only used when more than one-third of the columns are being used

UP TO N ROWS:When a full key is unknown and only one record is needed, the UP TO 1 ROWS appendage is added to the SELECT statementPreferred: SELECT FIELD1 FROM TABLE UP TO 1 ROWS. ENDSELECT.Avoid: SELECT FIELD1 FROM TABLE. EXIT. ENDSELECT

AggregatesWhen finding aggregates such as maximum, minimum sum, average, and count, a SELECT list with the aggregate function is used instead of programming the code

Nested LoopsNested loops are avoided. If unavoidable, take advantage of parallel cursor technique



Client:

Project:

RICEFW ID:

Description:

Programmer:

Reviewed by:

Date Reviewed:


Errors Number: ###





N/A Not Applicable

APPL Applicable


63 Yes Unnecessary moves are avoided by using explicit Work Areas ###

64 Yes LOOP…WHERE is used instead of LOOP/CHECK ###

65 Yes ###

66 Yes ###

67 No ###

72 Yes ###

73 Yes ###

74 Yes ###

75 No Preferably LOOP AT itab ASSIGNING <field symbol> is used ###

76 No Use Modify Internal table TRANSPORTING f1….fn as far as possible ###

77 No Append to be used instead of Collect ###

78 No ###

SORT79 Yes ###

General Optimization

80 No ###

81 Yes Perform SE30 on program ###

82 Yes Perform ST05 to analyze SQL statements ###

83 Yes Run transaction SCI. ###

84 No ###

85 Yes ###

86 Yes ###

86 Yes Authority-checks available where needed / requested ###

87 Yes Validate selection screen entries right away when applicable ###

88 No ###

89 Use IS/IS NOT INITIAL instead of hard coded comparisons ###

For READ operations, the key fields are specified for READ access explicitly

When performing BINARY search, the internal table must be first sorted by the key

When performing direct reads, the BINARY SEARCH is used only when the table contains more than 500 rows

CLEARClear the header line of the internal table After ‘DELETE’Clear the header line before ENDLOOPCLEAR the internal table header line after APPEND

REFRESHInternal tables are refreshed before using, not only at the beginning of the program. It is preferred to refresh just before they are used within a modular unit

FREEThe FREE command is used to release the memory allocated to internal tables when the program is finished processing the data in the table and when the following conditions exist:1. The internal table is large2. The internal table is sorted and reprocessed several times3. Program is processing several internal tables

OCCURSA number other than zero is only specified for the OCCURS parameter if the required storage is less than 8 kilobytes

All SORT statements are qualified with the BY option and limited to the fields that must be used to satisfy processing requirement

Sap Code InspectorWith extended syntax check (SLIN)

Avoid large tables such as CDHDR, CDPOS, BSEG, MSEG, MKPF, BKPF, VBFA

Does the ABAP run with appropriate “no rows selected” criteria and returns immediately?

Does the ABAP run quickly with an appropriate single row expected result?

Selection-screen for the program- Transaction input fields such as the sales order number, purchase order number should not be validated- Appropriate error, warning or information messages should be displayed- Variants should be created and included in the request number (wherever applicable)



Client:

Project:

RICEFW ID:

Description:

Programmer:

Reviewed by:

Date Reviewed:


Errors Number: ###





N/A Not Applicable

APPL Applicable


90 Global data declared in one place ###

91 Variables and constants declarations should be documented ###

92 Top Include used ###

93 ###

94 ###

95 ###

96 DATA statements defined locally for local variables ###

97 Use TYPEs for defining duplicate structures ###

98 Set up an internal field with the VALUE option ###

99 Use TYPE I for counter or loop index ###

100 Avoid type conversions ###

101 Consider the table type when constructing your SELECT statement ###

102 ###

103 Avoid unnecessary accesses into the database select ###

104 ###

105 Use commit work judiciously ###

106 ###

107 ###

108 ###

109 ###

110 Can these unnecessary select statements be removed? ###

111 Optimized SELECT Statements: array fetches into an internal table ###

112 Where possible, avoid accessing the same data more than once ###

113 Avoid selecting useless data that are filtered out later ###

114 Long SELECTs within the AT SELECTION-SCREEN event are avoided ###

115 ###

116 ###

117 AT preferred to ON CHANGE OF ###

118 CASE Preferred to IF ###

119 ###

120 WHILE Preferred to DO ###

121 ###

MOVE CORRESPONDING122 ###

Call transaction identified and described andCall subroutine described

Data declarations as far as possible are declared using like from a DDIC.

Parameter documented as input/output in Perform Statements and Form Statements

Within the WHERE clause, AND and OR statements exist that could be replaced by > and < statements

SELECT statements use as much of the primary key as possible (TRANSP and POOL tables)

Read through a large table processing records in “Blocks” (Array processing with OCCURS and UP TO nn ROWS)

Selection criteria hit on primary keys of large tables (minimizing the search)

Large selects exist that do not match any index. Always ensure an index is being used

Do large selects exist that do not match an index due to “skipping” index fields?

MOVEWhen possible, the destination operands are kept as the same data type as the source operands

All LOOPs, IFs, CASEs, and similar statements are broken down to their simplest form and nesting is not complicated unless absolutely necessary

IF/CASEWhen using the AND or OR operator the most likely elimination criterion is specified first

CLEAR Field for InitializationCLEAR field is used to initialize rather than explicit movesTable headers and work areas are CLEAR at the end of loop process

It's only used for small tables or tables where most, but not all, fields need to be moved



Client:

Project:

RICEFW ID:

Description:

Programmer:

Reviewed by:

Date Reviewed:


Errors Number: ###





N/A Not Applicable

APPL Applicable


123 ###

114 ###

115 ###

116 Forms declared in the order in which they are being used ###

TABLE INSPECTION

Object Attributes N/A <- Change value if required

117 ###

118 ###

119 ###

120 ###

120 ###

121 ###

Maintainability of code

120 Every code paragraph is preceded with proper comment ###

121 ###

122 Redundant code should be removed ###

When all fields need to be moved and the attributes for every field and position are identical, the table is MOVEd as a group

If there is any division in the program, then the denominator is checked for zero before division

COLLECTWhen COLLECT semantics are needed, the COLLECT command is used.Preferred: SELECT matnr werks lgort umlme FROM mard INTO (v_mard3-matnr, v_mard3-werks v_mard3-lgort, v_mard3-umlme). COLLECT v_mard3 into I_mard3. ENDSELECT.

Avoid: SELECT matnr werks lgort umlme FROM mard INTO (v_mard-matnr, v_mard-werks v_mard-lgort, v_mard-umlme). APPEND v_mard to i_mard. ENDSELECT.

LOOP at I_mard3 into v_mard3 COLLECT v_mard into I_mard2. ENDLOOP

Table NameFollows standard and naming convention (ABxxxxxxxx).

Short TextThe title is a concise description

Development ClassThe appropriate development class has been used.

Change RequestThe appropriate project standard for creating and associating tasks to change requests has been used.

Tables created should have:- Delivery class ‘A’- Client as the first key (unless client-independent)- Maintenance view created (if to be maintained manually)- Foreign keys should be defined- SAP data elements used where possible- Technical attributes correct

Technical settings (F7)- Data class (USER or USER1 is to be used when creating new customer tables) - Size Category- Buffering

Every form has the format of SAP standard form documentation and proper comments explaining the purpose and the parameters



Client:

Project:

RICEFW ID:

Description:

Programmer:

Reviewed by:

Date Reviewed:


Errors Number: ###





N/A Not Applicable

APPL Applicable


123 ###

124 All comments are in English ###

125 Text-elements should be used along with hard-coded literal ###

126 ###

Documentation

127 Ensure documentation exists ###

128 ###

Data Naming standards N/A <- Change value if required

129 ###

130 ###

131 ###

Quality

132 ###

133 ###

134 ###

Print Programs N/A <- Change value if required

135 ###

145 Header and footer texts comply with the Standard texts.(if any) ###

136 Code review done for all languages (if any) ###

146 ###

Screen Developments N/A <- Change value if required

147 Screen texts should always be referred to a data element ###

148 Validations on input screen elements done using chain/endchain ###

149 PF Status created as per the spec ###

150 Screen numbers created as per ABAP programming standards ###

Plant activation N/A <- Change value if required

151 Plant activation logic has been incorporated ###

BDC N/A <- Change value if required

152 Input file validation done and error message displayed accordingly ###

158 F4 help given in case user is not entering any filename ###

153 ###

159 Call transaction error messages are captured in an internal table ###

154 Is sy-subrc eq. 0 checked after a transaction? ###

160 Refresh Clear bdcdata done after a call transaction ###

Translations to be done in the customer language for the error messages provided

Pretty printer used for fresh developments. No pretty printer used for old enhancements

Documentation for newly created ABAP objects have been done (Eg. User defined tables, structures, etc.).

Field name- Standard abbreviations used- Standard prefixes and suffixes used- Data is grouped logically- Adequate documentation for German fields- Short text exists for each filed name

Data Element- Follows standard and naming convention (ABxxxxxxxx).xxxxxxxx SAP field name if possible

Domain- Follows standard and naming convention (ABxxxxxxxx).xxxxxxxx- Use existing domain names if possible

Y2K-DatesDates are in type DATE

NumbersNumbers are in type NUM or QUAN

MoneyMonetary values are in type CURR

Print Program and Layout set Customized for a given output Type(SPRO maintenance)

Different language layout-set programs are triggered according to customer-language or functional specifications.

Call transaction/BDC_SESSION method used as per the specification



Client:

Project:

RICEFW ID:

Description:

Programmer:

Reviewed by:

Date Reviewed:


Errors Number: ###





N/A Not Applicable

APPL Applicable


155 ###

161 ###

156 ###

162 ###

UNIT TEST PLAN INSPECTION

163 Complete Unit Test Plan with proper Cycles ###

164 ###

165 ###

166 ###

Report Criteria APPL <- Change value if required

167 Yes ###

168 Yes ###

169 Yes ###

170 Yes Test all logical variation in data to be reported ###

171 Yes Test every calculation ###

172 Yes ###

173 Yes ###

174 Yes Check that every selection criteria is processed correctly ###

175 Yes Test logical combinations of selection criteria as appropriate ###

176 Yes ###

177 Yes ###

178 Yes ###

179 Yes ###

If BDC_SESSION method is used and if unable to open session using BDC_OPEN appropriate message is given

If BDC_SESSION method is used and if unable to insert using BDC_INSERT appropriate message is given.

If BDC_SESSION method is used and if unable to close session using BDC_CLOSE appropriate message is given

Audit report displaying the records, which have been posted or not is shown. (If required)

Check that all test conditions included in functional design are included in Unit Test Plans

All information is transported to the required clients/systems. In particular, ensure client-dependient data (table contents, forms, etc) is transported to the necessary clients/systems so that tests are propertly carried out.

Test were conducted with HTML GUI in case the end user will use that GUI (not PC GUI).

Test all report and column headings are formatted exactly to report specifications

Test that page headers correspond to data printed for a particular page

All fields need to be verified against transactions and database tables

Verify that the formatting and spacing is identical to the functional design

Verify that all sorts and totals operate as specified in the functional design

Report/Screen standard features:- Line-size, line-count, heading or no-heading, defined according to list output. - Use standard line-sizes of 80,120 or 255 wherever necessary. - Features like navigation, format, color, using Unit/Currency option while writing Quantity/Currency fields should be present

If the program has selection screen, the selection fields must have value help (F4) wherever applicable. Use standard match code objects wherever possible.

Top-of-page event handled for all cases. Report displayed in accordance to it. Ex: - If the report has to display two kinds of headers for two different types of displays.

Correct event flow. The correct order is: - Initialization->At-selection screen->Start-of-selection->end-of-selection->top-of-page



Client:

Project:

RICEFW ID:

Description:

Programmer:

Reviewed by:

Date Reviewed:


Errors Number: ###





N/A Not Applicable

APPL Applicable


180 Yes ###

181 Yes ###

182 Yes ###

183 Yes If required, data is initialized in initialization event. ###

Interface & Conversion Criteria N/A <- Change value if required

184 Yes Test that data being processed are in the proper format ###

185 Yes ###

186 Yes ###

187 Yes ###

188 Yes Check that data was committed to database tables properly ###

189 Yes ###

190 Yes ###

191 Yes ###

192 Yes ###

193 Yes ###

194 Yes ###

195 Yes Test that data are exported in the correct format and sequence ###

196 Yes ###

197 Yes ###

198 Yes ###

199 Yes ###

Start of selection and end of selection events:- Data selection done in start-of-selection- Selected data processed after end-of-selection- Proper error handling done providing adequate error/warning/information messages.- If the error or warning message needs more explanation then Long Texts are to be used.

Do not perform database validation at the at-selection screen as far as possible.

List processing:- All Similar Fields are written below correct heading and in columnar format. E.g. ‘WRITE … UNDER’ variant of WRITE statement to be used- Amount fields displayed with currency key, unless specified not- Alignment of fields – Amount, quantity fields to be aligned right, Name, description fields to be aligned left, etc- All the events in the pf-status used shall be handled- Hotspots used at line-selection event- Correct color formatting to be used- SY-PAGNO cleared before any new print or leave to list-processing- At-user selection event handled

Test every data field through (and SAP display transaction, if applicable) to ensure that it was properly mapped

Test that the data is processed in background versus transactions or BDCs as specified in the functional design

If applicable, test every logical variation in the data to ensure that the screen flow continues as expected

Test that invalid data is recognized and properly reported per the functional specifications

Test that disaster recovery is properly handled per the functional specifications

If applicable, test that the object attributes are the same that in the specified in the technical design

Test that the number of records read are the same that in the input file

Test that the number of records converted are the same that the read one

Verify that the correct data entered is passed to the external system

Verify that the interface handles properly all logical variation in the data

Verify that export fields are of the correct length to handle maximum data lengths

Automatic generation after import option is provided in the interface definition.

Data sets are written into the file with proper length specification (Using the ‘describe table’ command), in order to avoid hard coding of length.



Client:

Project:

RICEFW ID:

Description:

Programmer:

Reviewed by:

Date Reviewed:


Errors Number: ###





N/A Not Applicable

APPL Applicable


200 Yes ###

201 Yes ###

Enhancement Criteria N/A <- Change value if required

202 Yes ###

203 Yes ###

204 Yes Test every logical data variation ###

205 Yes ###

206 Yes ###

207 Yes ###

Form Criteria N/A <- Change value if required

208 Yes ###

209 Yes Test any calculations that are made ###

210 Yes ###

211 Yes ###

OK-0 The criterion is met without further reworkOK-n The criterion is met after n-times reworkFAIL-n The criterion is not met after n-times rework. Some more rework is requiredN/A Not ApplicableAPPL Applicable

* Critical checks constitute grounds for code rejection if criteria are not met.** Comments are required when a criterion has not been met.

For files names a) Table used to read the relevant file nameb) If no entry found in the table, default file name should be used

Error handling:- Proper error handling is done as per the standards. - Errors can either be displayed on the screen or recorded in the protocol, as required. Errors occurring should be re-processable - Inbound interfaces should check for blank records in the input file.- Outbound interfaces should not have any blank lines in the output file.

Test every conceivable scenario in which the enhancement can be executed. Use screen prints with detailed test scripts to clearly document each step in the testing process.

Test cycles with multiple combinations of transactions such as Create, Change, Print, Delete, for a particular data entity

Test logical point at which the enhancement might be called, yet should not be called

Verify that any information entered into the system via the enhancement is properly committed to the database using a combination of standard SAP forms, reports, and display transaction

Validate that when an enhancement framework is ued that there are not BADI's, function exits, etc. available that can be employed.

A condition should be written to verify each field that is brought into the form comes from the appropriate field

Verify that the format and spacing match that of the functional design

Test the maximum length of every field to ensure that proper format is maintained



Client:

Project:

RICEFW ID:

Description:

Programmer:

Reviewed by:

Date Reviewed:


Errors Number: ###





N/A Not Applicable

APPL Applicable


# Criterion Comment on Criterion Status Others

1 ###

2 ###

3 ###

4 ###

5 ###

6 ###

7 ###

8 ###

9 ###

10 ###

11 ###

12 ###

13 ###

14 ###

15 ###

16 ###

17 ###

18 ###

19 ###

20 ###

21 ###

22 ###

23 ###

24 ###

25 ###

26 ###

27 ###

28 ###

29 ###

30 ###

31 ###

32 ###

33 ###

34 ###

35 ###

36 ###

37 ###

38 ###

39 ###

40 ###

41 ###

42 ###

43 ###

44 ###

45 ###

Documents

Copy of Code Review Checklist v1(1).0