・形式 ルール
・Naming ルール
■定数
プリフィックスにCON_を使用し、すべて大文字とする。
CON_NO_DATA CONSTANT VARCHAR2(1) := ‘3’;
CON_ERROR CONSTANT VARCHAR2(1) := ‘1’;
CON_NORMAL_END CONSTANT VARCHAR2(1) := ‘2’;
■RECORD型定義,TYPE型定義,例外型定義などの定義関係
型の定義はすべて大文字とする。単語と単語は_(アンダースコア)でつなぐ。
□特殊変数の型によるプリフィックスを付与すべ
cur_ CURSOR cur_list_master
rec_ RECORD rec_dept_line
pin_ PLS_INTEGER pin_count
tbl_ TABLE tbl_code_master
■関数の引数
in_またはout_またはinout_をプリフィックスに使用する
PI_ INPUT引数
PO_ OUTPUT引数
□関数の名称
□意味がある関数名称の本体部分には、用途を表す完結した名前を大文字と_(アンダースコア)を使用して付けること。
□プロシージャ名は NAME_ARRAY_INIT やFILEPOINTER_CLOSE のように分類詞（名称）で始める。
・コメントルール
・その他書式 ルール
■インデント インデントの幅は4カラムのタブとする
・構造性ルール
■物理的な機能実現（※物理指標）以外、以下の点を十分考慮する
・性能（Performance) ※物理指標
・ロジック正規化（更新性/柔軟性) ※論理指標
・理解性（Simple) ※論理指標
・テスト容易性(Point Test/テストケースの削減) ※論理指標
■技巧的なコーディングを使用する場合、ソースの保守性を十分考慮する
■性能（Performance)
性能が必須要素ですが、目標値以上の性能改善が不要
■動的な機能を使うと、柔軟性ＵＰの反面、パフォーマンス低下の可能性がある
性能許可の範囲内、動的な機能を使う
■動的なSQL文の実行がSQL DBMS_SQLパッケージを使用する
■読み手の立場で、コーディング
わかりやすいコーディングを行う プログラムは、記号の集まりではなく文章である。
書く手間を惜しまず読み手に無理な推測をさせないように適当なコメントを付与や、
読みやすいコーディングetcの工夫を行うべきである
一般的ではない命令や複雑な仕組みを使う等は論外である。
そのようなプログラマーの自己満足がプログラムの寿命を縮めるばかりか、障害の原因となることも十分考慮すべきである。
自らの技術・能力は保守性の向上にこそ発揮すべきである。
■フィールド変数のデータ型はかならず%TYPEを使用すべき
■例外処理
参考：PLSQL_例外発生行番号およびTrace情報の出力
■機能関数
□原子性
機能関数が明確的な単一機能を実現する
□カブセル性
機能関数のINPUT/OUTPUTが明確的なもの
□機能関数ではトランザクションのコントロールしない
・性能ルール
□FORよりもFORALLを使うべ （配列(バルクSQL)の使用）
FORALLはパフォーマンスが30%程度向上する。FORALLが使用できないか検討してみること。
CREATE TABLE employees_temp AS SELECT * FROM employees;
DECLARE
→TYPE NumList IS VARRAY(20) OF NUMBER;
→depts NumList := NumList(10, 30, 70); — 配列をセット
BEGIN
→FORALL i IN depts.FIRST..depts.LAST
→DELETE FROM employees_temp WHERE department_id = depts(i);
→COMMIT;
END;