一、PL/SQL编程规范之大小写
就像在SQL中一样，PL / SQL中是不区分大小写的。其一般准则如下：
关键字（BEGIN， EXCEPTION， END， IF THEN ELSE，LOOP， END LOOP）、数据类型（VARCHAR2， NUMBER）、内部函数（LEAST， SUBSTR）和用户定义的子程序（procedures， functions，packages），使用大写。
变量名以及SQL中的列名和表名，使用小写。
二、PL/SQL编程规范之空白
空白（空行和空格）在PL/SQL中如同在SQL中一样重要，因为它是提高代码可读性的一个重要因素。换句话说，可以通过在代码中使用缩进来体现程序的逻辑结构。以下是一些建议：
在等号或比较操作符的左右各留一个空格；
结构词（DECLARE， BEGIN， EXCEPTION， END，IF and END IF， LOOP and END LOOP）居左排列。另外，结构中的嵌套结构要缩进三个空格（使用空格键，而不是Tab键）；
主要代码段之间用空行隔开；
把同一结构的不同逻辑部分分开写在独立的行，即使这个结构很短。例如，IF和THEN被放在同一行，而ELSE 和END IF则放在独立的行。
三、PL/SQL编程规范之命名约定
使用以下前缀对于避免与关键字和表名列名相冲突是很有帮助的：
v_变量名
con_常量名
i_输入参数名，o_输出参数名，io_输入输出参数名
c_游标名 或者 游标名_cur
rc_ Ref Cursor名
r_Record名 或者 Record名_rec
FOR r_stud IN c_stud LOOP…
FOR stud_rec IN stud_cur LOOP
type_名称，名称_type （用户定义的类型）
t_表名，表名_tab （PL/SQL 表）
rec_Record名，Record名_rec （Record变量）
e_异常名 （用户定义的异常）
包的名称应该描述包内的存储过程和函数主要所完成的功能
存储过程的名称应该描述该存储过程所执行的动作
函数的名称应该描述所返回的变量
例如：
PACKAGE student_admin
– admin 后缀可能是用于表示管理功能。
PROCEDURE remove_student （i_student_id IN student.studid%TYPE）；
FUNCTION student_enroll_count （i_student_id student.studid%TYPE）
RETURN INTEGER；
四、PL/SQL编程规范之注释
PL/SQL中的注释如同SQL中的注释一样重要。他们应该解释程序的主要部分和所有关键的逻辑步骤。
使用单行注释（–）而不是多行注释（/*）。即使PL/SQL对这些注释做同样处理，这样在代码完成后进行调试也会容易些，因为你不能在多行注释中嵌入多行注释。换句话说，单行注释代码中可以部分取消注释，而在多行注释代码中则不行。
五、其他的建议
对于PL/SQL中嵌入的SQL声明，使用相同的格式化指南来决定这些声明应该如何在代码块中出现
提供一个头部注释，用于说明代码块的用途并列出创建日期和作者名字。并且每个修订版都要有一行注释，包含作者名、日期和修订版描述。
例如：下面的这个示例体现了上述建议。请注意该示例还使用了等宽字体（Courier New），因为每个字体占据同等宽度可以使格式化更加简便。等比例空格字体会隐藏空格使得行间对齐比较困难。多数文本和程序编辑器默认使用等宽字体。
--------------------------------------------------------------------------------------------------------------------------
newkid 大师的点评
16楼说得不错，抄书的吧？ 1. 非关键字小写，关键字大写，用下划线分隔，用前缀区分变量与表列名。不强求变量初始值。 2. 永远只捕获可预测异常。在最外层（直接被客户调用的一层）捕获WHEN OTHERS并调用一个通用子过程写入日志。子过程里将DBMS_UTILITY.FORMAT_ERROR_BACKTRACE写入表。然后继续RAISE。 应用主动抛出的异常用RAISE_APPLICATION_ERROR(-20001,'XXX: ..........')，其中XXX为自定义错误代码。 DML ERROR LOG以及BULK EXCEPTION只在ETL类的代码中使用，不在事务中使用。前提是数据之间没有联系，错误是可以事后处理的。 3. 大部分用静态SQL，万不得已才用动态SQL. 动态SQL的写法要求同静态SQL, 注意可读性。 大部分情况下用绑定变量，仅在非密集查询类且绑定变量使得计划恶化才用常量。 4. 没必要的SQL当然不用（比如可用赋值取代FROM DUAL），具体问题具体分析。 如果是相对静态的信息，不需要“事先查一遍”。一致性要求高的操作，要么用一个SQL完成，要么在事务的开始加上行锁使得操作串行化。 5. 尽量用SQL取代CURSOR，这个也是具体问题具体分析。 其他的话题都太大了。