PL/SQL编程规范

一、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，这个也是具体问题具体分析。
其他的话题都太大了。