Sl No.

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

Good Coding Practices Code sharing - If a piece of code more than 104 lines are needed in more than one place, a function or procedure for the same is recommended. Proper indentation is to be followed Code should not go beyond the screen size i.e. horizontal scrolling should not be required to view the code. (Restrict lines to a width of 80 columns, whenever a line exceeds 80 columns, cut it logically so that it is not continuous on more than one line.) Variables can be initialized during declaration, if needed. Boolean should be initialized before the start of a loop. Limit the scope of variables to the area that they are needed. Variables needed within a single script are to be declared as local variables. Variables needed across an entire application are to be declared as global variables. Ideally global variables should be avoided. Blocks containing DML statements should have at least one Exception handler. In Declaration section the following order should be maintained, global variables followed by local variables followed by cursor , function declaration. Avoid initializing variables inside a loop. Try to avoid Dynamic SQL as far as possible. Try to avoid GoTo statements. E.g.-- The code checks whether invoice status is PAID IF l_inv_rec.status = PAID THEN ....... ELSE ...... END IF; Add comments in the Package Header Add show errors to all packages, procedures and functions. In the case of Packages add show errors after Package Specification also. Comments for program specific hard coding - Put comments where front end and back end communicate with hard coded data values. Comments in code - Write comments in code for business logic Do not do any commit in a common procedure. In INSERT statements, do not assume the order of the fields in the table. The order of fields must be mentioned explicitly, in the INSERT statement. In select/insert/update/delete statements, use UPPER function for PKs, FK's, Indicators and Flags. Upper function should not be used for Description fields. Do not set key fields in update statements. Avoid using TRUNC function in comparisons and during insert/update of all. When comparing two variables for equality/inequality, if the variables can take NULL values, use NVL(<variable>, ) for comparison.

All flags shall be Varchar2(1) and shall be represented by Y and N. Conversions should not be implied. Always a format mask must be used when TO_CHAR(), TO_DATE conversion functions are used. The program must be modular in structure. The program should have a single RETURN statement. Avoid using multiple return statements. Avoid the use of global variables in the program as far as possible. Pass parameters between subprograms. Use parameterized cursors as far as possible instead of using global variables.

Block Type IF .. THEN ... ELSE END IF; EXCEPTION WHEN .... FOR LOOP END LOOP; FOR LOOP END LOOP; WHILE LOOP END LOOP; LOOP ... EXIT WHEN condition; END LOOP; DECLARE ... BEGIN ... ... EXCEPTION ... END

Intendation Guidelines Indentation of executable statement is same as condition There should be a single space between IF and condition and a single space between condition and THEN. WHEN OTHERS should start from 5th character(i.e. P) of EXCEPTION There should be a single space between FOR and the loop variable and LOOP should be in the next line. Indentation of executable statement is 4 space. There should be a single space between WHILE and the loop variable and LOOP should be in the next line. Indentation of executable statement is 4 space.

Indentation of executable statement is 4 spaces. There should be a single space between WHEN and condition. The declaration of variables should have an indentation of 4 spaces(i.e. it should start below A of DECLARE). The statements in the BEGIN block should have an indentation of 4 spaces(i.e. it should start below N of BEGIN).

SELECT statements

All the other keywords in the SELECT statement should be left aligned to the SELECT keyword. All the other keywords in the UPDATE statement should be left aligned to the UPDATE keyword. All the table fields specified in the SET statement should be left aligned.

UPDATE statements

INSERT statements

All the other keywords in the INSERT statement should be left aligned to the INSERT keyword.

Examples IF X > Y THEN X :=Z; END IF;

EXCEPTION WHEN OTHERS FOR l_num_loopcnt IN 1..3 LOOP DBMS_OUTPUT.PUT_LINE (l_num_loopcnt); END LOOP; WHILE l_num_loopcnt < 3 LOOP DBMS_OUTPUT.PUT_LINE (l_num_loopcnt); END LOOP;

LOOP DBMS_OUTPUT.PUT_LINE(l_num_loopcnt); EXIT WHEN I >= 3; END LOOP; DECLARE count NUMBER := 3; BEGIN IF count > 3 THEN DBMS_OUTPUT.PUT_LINE( > 3 ); ELSE DBMS_OUTPUT.PUT_LINE( <= 3); END IF; EXCEPTION WHEN OTHERS THEN ------END SELECT item_id FROM equipments WHERE equipment_id = 100; UPDATE equipments SET equipment_name = PC WHERE equipment_id = 100;

INSERT INTO equipments (equipment_id, equipment_name) VALUES (101, MODEM);

S. No. 1 2

3 4 5 6 7 8 9 10 11 12 13

14

15

General Guidelines for Coding In INSERT statements, do not assume the order of the fields in the table. The order of fields must be mentioned explicitly, in the INSERT statement. While fetching records using SELECT statement, do not use * in the statement. All the columns must be mentioned explicitly. When comparing two variables for equality/inequality, if the variables can take NULL values, use NVL(<variable>, ) for comparison. Do not use IF VARIABLE = NULL. This always returns FALSE. Conversions should not be implied. A format mask must be used when TO_CHAR(), TO_DATE conversion functions are used. The program must be modular in structure. Ideally a program should have only one RETURN statement. If possible try to avoid using multiple return statements. Avoid the use of global variables in the program as far as possible. Pass parameters between subprograms. For common validations, do not hard code, use standard pl/sql procedures. Have the application common functions in the cms_util package. For common functions, instead of writing of your own, find them in the utility packages and use them. Never code more than one statement in a line. Reset loop index, loop counter and variable used with in a loop before the loop explicitly. Use meaningful aliases in DML statements. Never use A,B as alias. If you are using SYSDATE more than once in the code, better assign to a variable and use that variable in place of SYSDATE. While creating table, have the primary keys defined first and then the columns should be in alphabetical order. If it is a big table, have all the columns in excel, sort and then define in the table. TRUNC should be used in date comparison, e.g., TRUNC(SYSDATE) > TRUNC(scheduled_date)

Item

Standards/Guidelines Use Parameterized Cursors Cursor records should be passed to the called program from the calling program. It cannot be accessed globally in all subprograms within the pl/sql procedure. When no data is found, check that the closing of the cursor is handled properly, in case the cursor is handled by using OPEN, FETCH & CLOSE cursor When a record in a cursor is to be processed in a loop, try to use for cursor loop, as it handles the OPEN, FETCH & CLOSE of the cursor implicitly. When an error condition is trapped and error message is set, use SUBSTR () function to prevent value_error occurring due to truncation of message. Every PL/SQL block should have an EXCEPTION block. All functionally related exceptions, must be handled before the WHEN OTHERS THEN exception handler. Avoid putting any business logic in Exception block. Variables, which are based on database, must be defined as <tablename.fieldname>%TYPE. Always qualify the variable with source table name, whenever the same column source appears in more than one table. Initialise the variables during definition itself as far as possible. If more than one variable is fetched in a cursor, use a %ROWTYPE variable instead of separate variables.

Cursor Handling

Error Handling

Variables and Datatypes

Examples

CURSOR iosc_customers_cur ( in_chr_customer_number iosc_customers.customer_number%TYPE, in_num_company_number iosc_customers.comapny_number%TYPE) IS SELECT customer_id FROM iosc_customers WHERE customer_number = in_customer_number AND company_number = in_company_number;

Examples Table name inv_equipment Table column name equipment_id Variable name - ln_equipment_id ln_equipment_id inv_equipment.equipment_id%TYPE; ln_cut_off number := 12;

S. No.

Formatting Guidelines

Within a package, define private variables first, then private procedures, and 1 finally public procedures. Always end procedures and packages by following the end statement with 2 the procedure or package name to help delineate procedures. Indent code logically. Using increments of 4 spaces provides an easy way to 3 track your nested cases. Use to start comments. To easily comment out large portions of code 4 during debugging use /* ... */. 5 Indent comments to align with the code being commented. When commenting out code, start the comment delimiter in the leftmost 6 column. When the code is clearly no longer needed, remove it entirely. Use uppercases and lowercases to improve the readability of your code (PL/SQL is caseinsensitive). As a guideline, use uppercase for reserved words 7 and lowercase for everything else. Avoid deeply nested IFTHENELSE condition control. Use IFTHENELSIF 8 instead.

S. No.

SQL Coding Guidelines

Use select from DUAL instead of select from SYS.DUAL. Do not 1 use SYSTEM.DUAL. Use SELECT statements only if table is accessed with the primary or unique key. This can fetch 0 or 1 row. Use NO_DATA_FOUND 2 exception to handle no records found condition. If you want to SELECT into a procedure parameter, declare the parameter as IN OUT, whether or not you reference the parameter 3 value, unless the parameter is a field. singlerow SELECT that returns no rows raise the exception NO_DATA_FOUND. An INSERT, UPDATE, or DELETE that affects no rows does not raise an exception. If you need to handle NO_DATA_FOUND exceptions, write an exception handler. Do not code COUNT statements to detect the existence of rows unless that 4 is your only concern. When checking the value of a field or PL/SQL variable against a literal, do the check in PL/SQL code, not in a WHERE clause. You 5 may be able to avoid doing the SQL altogether. ????? Do not check for errors due to database integrity problems. For example, if a correct database would have a table SYS.DUAL with exactly one row in it, you do not need to check if SYS.DUAL has zero 6 or more than one row or if SYS.DUAL exists.

S. No.

General Performance Improvement Guidelines For sub-queries use EXISTS rather than using the IN statement, as far as possible. Use of NOT EXISTS is not recommended. Avoid NOT 1 IN

While writing SQLs, put the largest tables last in from clause. Put 2 most limiting condition, first in where clause. 3 Avoid using unnecessary Joins. 4 Use BETWEEN function for differential validation. 5 Instead of using count(*) use count(indexed column). 6 Do checks for FK validations, only if delete is not happening. Only indexed fields are to be used in the ORDER BY clause to the 7 extent possible.