Coding Standards for Oracle Applications Programming using PL/SQL

Abstract
This general document provides the Coding Standards which are followed in the implementation and development of components in Oracle Applications Programming using PL/SQL.

Contents
INTRODUCTION ........................................................................................................................ 4 SCOPE............................................................................................................................................ 4 OVERALL CODING STANDARDS .......................................................................................... 4 SQL CODING STANDARDS ..................................................................................................... 5 PL/SQL CODING STANDARDS ............................................................................................. 6 SQL* PLUS CODING STANDARDS ...................................................................................... 8

INTRODUCTION
The purpose of this document is to establish a standard development approach for technical object naming conventions and coding standards. This is accomplished through strict standardization of the approach. Use of coding standards will Facilitate maintenance. Improve code efficiency.

SCOPE
This document assumes objects are developed for an Oracle Applications using PL/SQL. This includes operating system directories and files.

OVERALL CODING STANDARDS

This section describes standards relevant to all types of Oracle Applications programming. Standard ALL-0001 Description Avoid hard-coding values. Comments In an Oracle Applications environment, hard-coding can be avoided by using value sets, lookups and/or profile options. This includes packages, procedures, functions, triggers and views. In cases where security warrants it, executable code may be contained in a custom schema. This includes tables, indexes (including custom indexes on Oracle Applications tables), sequences, etc. For tables, GRANT ALL to APPS, for programs, GRANT EXECUTE to APPS. Examples include: Always indent by the same number of characters within a package (or procedure or function). Make sure each table aliases remain constant from one occurrence to another. Align keywords consistently per statement type (SELECT, INSERT, etc.). Align parameters consistently.

ALL-0002

Executable code and types should be located in the APPS schema. All other database objects should be located in the custom schema. All objects in the custom schema should grant APPS the appropriate privileges. Use a consistent style of indenting and capitalization throughout a program.

ALL-0003 ALL-0004 ALL-0005

Standard ALL-0006

Description Define SQL*Plus concurrent program executables to execute PL/SQL stored programs.

ALL-0007 ALL-0008

Keep all code within the first 80 characters of a line. Use spaces to align code.

Comments In general, because of the nature of global variables and concurrent program concurrency, define PL/SQL type concurrent programs using the SQL*Plus execution method. This will effectively ensure each user has his own copy of the program. This makes the code easier to read when viewing it in UNIX, where it will ultimately be installed. Some editors use TAB characters and combinations of TAB and space characters to align code. This makes the code difficult to read if using a different editor. (In TOAD, select Edit > Editor Options from the menu. Expand General Options and uncheck Insert TABs as spaces and not #9 characters and uncheck Insert mix of TAB/space for optimal fill. To validate if code is following this standard, view the code in NOTEPAD or vi and verify the alignment is intact.

SQL CODING STANDARDS

Standard SQL-0001 Description Use EXPLAIN PLAN. Comments Use an explain plan during development when writing complex SQL statements to make sure the statement is performing as expected. As Oracles SQL optimizer is always being improved upon with each new database release, use hints only when the performance of the statement warrants it. Statements that contain database links are not as easily portable to different environments and are more difficult to read. (NOT) EXISTS is more efficient than COUNT, especially when the table has many rows. Use COUNT only when the number of rows is needed.

SQL-0002

Use hints sparingly.

SQL-0003

Use synonyms to hide database links. Use EXISTS or NOT EXISTS in WHERE clauses instead of COUNT.

SQL-0004

PL/SQL CODING STANDARDS

This section describes programming. Standard PLS-0001 standards relevant to embedded-SQL and PL/SQL

Description Use packages when defining procedures and functions instead of defining standalone procedures and functions.

Comments Packages provide several advantages over standalone code: Global variables Modularized code Prevents the invalidating of dependent packages if just the package body is changed

PLS-0002 PLS-0003

Follow the naming standards for PL/SQL objects above. Use %TYPE and %ROWTYPE when declaring variables and parameters. Use the CONSTANT keyword in declarations when the value of an identifier is not going to change. Remove unused variables from code. Separate distinct words in an identifier name with underscores (_). Functions should only have IN parameters. Boolean functions should return either TRUE or FALSE. Functions should have only one RETURN statement.

PLS-0004

Using %TYPE and %ROWTYPE anchors will ensure variables match their corresponding database columns. Using the CONSTANT keyword will prevent accidentally changing the values via an assign statement.

PLS-0005 PLS-0006

PLS-0007 PLS-0008 PLS-0009

Keep functions pure by avoiding output mode parameters (OUT and IN OUT). Avoid coding Boolean functions that return NULL. Too many return statements make code difficult to read.

Standard PLS-0010

Description Package specifications should comment programs using the template shown at the right.

PLS-0011

Private programs should include comments after the IS keyword.

PLS-0012

Document a packages change history in the specification and body as appropriate.

PLS-0013

Document multi-line change descriptions within a block as shown at the right.

PLS-0014

Document single-line change descriptions as shown at the right, either next to the line or directly above the line.

Comments /* ** NAME ** program_name short description ** DESCRIPTION ** A paragraph or two describing the ** programs functionality. For ** function programs, this section ** should describe the return value. ** NOTES ** This section contains technical ** implementation notes. It may be ** omitted if there is nothing ** significant. ** ASSUMPTIONS ** Clearly state the assumption on ** which your program is based. ** PARAMETERS ** p_parameter1 ** This parameter... ** p_parameter2 ** This parameter... */ PROCEDURE xxx IS -- This procedure... BEGIN . . . END xxx; PACKAGE [BODY] xxx IS -- Modification History: -- By Date Description -- -------- ----------- --------------- username DD-MON-YYYY Short descrip-tion of -changes -- XX: DD-MON -- This change... . . (Changed code here.) . -- END OF CHANGES -- XX: DD-MON Description of change

Standard PLS-0015 PLS-0016

Description At a minimum, each block should be commented. Blocks should be kept to a page length, approximately 60 lines of code. Use a common error package for handling errors. Use a common debug package. Use BULK COLLECT and FORALL when prudent. The main (top-level) program should have an exception handler such that no exception goes unhandled. Capitalize keywords and keep user-defined identifiers in lower-case.

Comments

If a packaged program is longer than a page, consider creating one or more private programs to encapsulate that logic.

PLS-0017 PLS-0018 PLS-0019 PLS-0020

This option may not be wise for cursors that return a lot of data. If a sub-program needs to raise an exception to the calling program, it should log the error in its exception handler and raise or re-raise an exception.

PLS-0021

SQL* PLUS CODING STANDARDS

This section describes standards relevant to SQL*Plus scripts. Standard SQP-0001 SQP-0002 Description Assign all input parameters to substituiton variables at the beginning of the script. Use EXEC to execute PL/SQL stored programs. Explicitly code WHENEVER SQLERROR and WHENEVER OSERROR statements Record changes to the script at the beginning (top), using the format as shown to the right. Comments

Avoid using anonymous PL/SQL in SQL*Plus as it makes the script more difficult to read and leads to less modular code.

SQP-0003 SQP-0004

REM REM REM REM deREM REM

Modification History By Date Description -------- ----------- ------------username DD-MON-YYYY Short scription of changes