Code Review Checklist

Module: Seq Issue No. GENERAL: Never use 1. Priority High Code Segment Reviewer: Status/Comments

2.

3.

sy_user_id.current_entity except to default entity in parent block upon form invocation. Never use format masks YY in a date field. This includes form items, or to_char(date) and to_date(char) function calls. Where clauses: Must be particularly careful of null columns. For example: code like: Where a.item_no = b.item_no and a.item_style = b.item_style

High

High

4.

5. 6.

7.

is wrong. Item style can be null. Must use proper entity_all in the where clauses. In the above example, it should also have one more line like and a.im_entity_all in (b.im_entity_all, ALL). Customer, Item, Project, ct_addr_code, ar_cust_addr_code, ap_vend_addr_code all of them require either the proper entity_all or entity in the where clause. Thats why using get_ _db is much safer. Make sure we use the right entity_all. Cust-entity-all is no good for item, for example. Typecast local and parameter variables (use %TYPE and %ROWTYPE) wherever possible. Failure to use them causes lot of heartburn later on. There should be no unused variable, commented out code, unused program-units, triggers, etc.

High

High Med

Med

FORMS: Use date datatype for date items 1.

in a form. This prevents implicit conversions, which are source of many Y2K problems. Also use proper masks if

High

94228705.doc

Page 1 of 5

04/24/12 10:19 A4/P4

Code Review Checklist

2.
displayed/enterable. Whenever passing date as a parameter or a global to another form/report/procedure, pre-empt implicit date conversions by putting explicit conversion with RR date format mask. PARAMETER OF DATE DATATYPE SHOULD NEVER BE USED. Any items populated in INIT_PARENT and ADDITIONAL_INIT_PARENT triggers should be in the PARENT block, not CTL_* block. Conversely, if you are populating items in PARENT block, these items should be dependent on :Parent.entity and the the code to populate them should be in INIT_PARENT or ADDITIONAL_INIT_PARENT . Never use $$DATE$$ or $ $TIME$$ or $$DATETIME$$ these get the time on the client not reliable. Instead use SYSDATE. That too, should usually be selected in INITIALIZE_FORM trigger and stored in the form (SYSDATE makes a trip to the server every time it is used). There are a few exceptions where you may need to get the time as of now and not as of when the form was invoked. In such cases, it should get SYSDATE again. CTL_1/2 block items: names should be meaningful to another programmer. CTL_1/2 block items: Dependent on entity? Then they should be in Parent block instead. CTL_1 block items should not be navigable. Buttons should not be navigable. Look for DB procedure/function calls with more than 60 parameters could cause ORA-04062 error when run in another schema. Also look for select * from using the asterisk makes it

High

3.

High

4.

High

5. 6.

High High

7. 8. 9.

High High High

10.

High

94228705.doc

Page 2 of 5

04/24/12 10:19 A4/P4

Code Review Checklist

dependent on the ordering of the columns. Could fail in another schema. Property Classes for Form, Blocks, Frames, Canvases, LOVs, GUI items, Windows. Key-triggers: Since user may not hit the key need to make sure we are covered even if user does not use the key. CALL_FORM: Should use the standard class from the library. Must pass :Parent.entity to the called form if the context being passed requires entity. SET_ITEM_PROPERTY( ENABLED,): Lot of time fails when the user is sitting on that item itself. The program must check for that and then handle it. POST-QUERY Triggers with more select from DB. A view could have been better. Or at least, may be one package or prcedure to replace several separate select statements. Prompt or hint-text or error message on a Sub-entity column should refer to it as entity, not sub-entity. See how default values are populated: a) Copy value from should not be used unless in relation. Use initial value instead. b) Defaulting in pre-text-item trigger is usually a bad practice: since it does not get executed until the user moves into that field. Can result in Mandatory Column error. May be used only in cases where the default value depends on another field still should check if the value is already populated, then probably should not default. c) Defaulting in pre-insert or pre-update trigger: should be avoided if the field is user-enterable. If it can not be avoided, at least make

11. 12.

High High

13.

High

14.

Med

15.

Med

16.

High

17.

94228705.doc

Page 3 of 5

04/24/12 10:19 A4/P4

Code Review Checklist

sure it does not overwrite user-entry in pre-insert trigger (default only if null). d) Defaulting in when-newrecord-instance causes problems, too: can cause validations and updates even if the user did not make change. Also when you go into a new record and try to come back, it stops with "Do you want to save the changes question. So the best option is to use the default value as much as possible. Others may be used in rare cases, but must take care of these issues. Get_item_property( data_base_value) on a date item has an ORACLE Y2K bug should not be used on date items until ORACLE fixes it. Parent block: Should be nonnavigable when user does not have change-entity privilege. Also when called from another form with context. Also, must receive :parent.entity along with other context from the calling form and just query up that entity.

18.

19.

High

Procedures/Packages: Look for Proper Exception/error 1. 2. 3. 4. 5. 6. 7.

handling. Refer to standards doc on intranet. Get procedures used whenever appropriate. Well documented with comments good for another programmer. Existing procedures used wherever appropriate. Explain Plan run for any major/new/repeating query clause. Enough future variables for commonly used procedures/functions. Variables named properly: a) l_.. for local variables b) p_.. for parameters passed into the form. c) Cp_.. for cursor

High Med High High High Med High

94228705.doc

Page 4 of 5

04/24/12 10:19 A4/P4

Code Review Checklist

parameters rest of the name meaningful to another programmer Error numbers must not be duplicated. Prefix and error number together must be unique. ABOVE ALL DUPLICATION OF CODE MUST BE AVOIDED.

8. 9.

High High

TABLES/VIEWS/COLUMNS Any table/view that has 1.

customer no must have custentity-all or entity. Any table/view that has item-no High 2. must have item-entity-all or entity. Any table/View that has account High 3. (no) must have acct entity-all or entity. Any table/View that has Project 4. High No/Job no must have entity. Comments in table/column 5. High creates. Legends where appropriate. The column comments go into tech doc, please pay attention to make sure they are meaningful. Column names: Date fields 6. Med should end with _date, amt fields should end with _amt. Same is true for user_id, user_ref, emp_no, project_no, etc. Make sure constraints, unique 7. High indexes, foreign keys, etc. have been considered when creating a new table or adding new column(s) to an existing table. Column name Status is 8. High usually meant for application specific statuses (like Open, Closed, etc.). Last_status, instead, is used for Added, Changed, Deleted, and is needed if necessary to retain history. OTHERS: In addition to this checklist, please watch out for other possible problem areas: abstruse code, dependence on untenable assumptions (for example: not using NVL for nullable columns in where clause), statements that are nested too deep to read, fetch/update out of sequence, closing cursor inside if .. then, etc.

High

94228705.doc

Page 5 of 5

04/24/12 10:19 A4/P4