PLSQL编码规范细则.docx

PLSQL编码规范细则.docx

《PLSQL编码规范细则.docx》由会员分享，可在线阅读，更多相关《PLSQL编码规范细则.docx（25页珍藏版）》请在冰豆网上搜索。

PLSQL编码规范细则

PLSQL编码规-细则

文件编号：

版本：

1.1

拟制　

审核

会签

标准化

批准

XXXXXX公司

XXXIT部

目录

前　言4

1范围5

2术语和定义5

2.1原则5

2.2规则5

2.3建议5

2.4说明5

2.5正例5

2.6反例5

3代码布局5

4注释9

5命名规则14

6可读性20

7变量21

8函数与过程22

9程序效率24

10异常处理25

11数据库触发器标准26

12SQL性能优化技术26

版本变更记录

版本号

拟制/修改日期

拟制/修改人

修改记录

批准人

注：

1）拟制、审核、会签、批准不走电子流程时，必须用钢笔或签字笔填写，不得用铅笔、圆珠笔填写，不得涂改。

<本模板中用“<>”括起来的内容包括本段，是编写指导，在最终的文档中应予以删除。

其它内容应予以保留。

如果某节内容无需填写，则在该节下写“无”，而不要将本节删除或不填写任何内容（留白将无法判断：

是本节内容无需填写还是因为疏忽而忘了填写。

）>

前　言

编码规范包括总则和细则两部分。

总则部分是对编码的总体性规范要求，适用于多种编码语言；细则部分是在总则的规范要求下，针对具体语言的特点而提出的规范要求。

本规范是编码规范的细则部分，适用于PLSQL编程语言。

编写本规范的目的是为了进一步规范PLSQL软件编程风格，提高软件源程序的可读性、可靠性和可重用性，确保在开发成员或开发团队之间的工作可以顺利交接，不必花很大的力气便能理解已编写的代码，以便继续维护和改进以前的工作，提高软件源程序的质量和可维护性，减少软件维护成本。

本规范的内容包括：

排版、注释、标识符命名、可读性、变量、结构、函数&过程、可测性、程序效率、质量保证、代码编辑&编译&审查、代码测试&维护等。

规范最后给出了一个编程实例供软件人员参考。

本规范分成规则性和建议性两种：

对于规则性规范，要求所有软件开发人员严格执行；对于建议性规范，各项目编程人员可以根据实际情况选择执行。

自本规范实施之日起，以后新编写的和修改的代码均应执行本规范。

1范围

本标准规定了PLSQL语言的编程规范，主要包括排版、注释、标识符命名、可读性、变量、结构、函数&过程、可测性、程序效率、质量保证、代码编辑&编译&审查、代码测试&维护等。

本规范自生效之日起，对以后新编写的和修改的代码有约束力。

2术语和定义

下列术语和定义适用于本标准。

2.1原则

编程时应该坚持的指导思想。

2.2规则

编程时必须遵守的约定。

2.3建议

编程时必须加以考虑的约定。

2.4说明

对此规则或建议的必要的解释。

2.5正例

对此规则或建议给出的正确例子。

2.6反例

对此规则或建议给出的反面例子。

3代码布局

代码布局的目的是显示出程序良好的逻辑结构，提高程序的准确性、连续性、可读性、可维护性。

更重要的是，统一的程序布局和编程风格，有助于提高整个项目的开发质量，提高开发效率，降低开发成本。

同时，对于普通程序员来说，养成良好的编程习惯有助于提高自己的编程水平，提高编程效率。

因此，统一的、良好的程序布局和编程风格不仅仅是个人主观美学上的或是形式上的问题，而且会涉及到产品质量，涉及到个人编程能力的提高，必须要引起重视。

【规则3-1】行应当限制在80个字符以内。

超过80个字符的行应当在低优先级操作符处拆分成新行，操作符放在行首。

拆分出的新行相对于第一行要缩进两个字符的空格，保持排版整齐，语句可读。

说明：

一般源代码每行的字符数不得超过80，除非只剩下一个单词。

如一行源代码超过了80个字符，可在逗号和操作符后面开始换行，并相对第一行缩进2个空格，或相对当前行做调整。

正例：

例1：

BEGIN

SELECTSUM（quantity）

INTO:

zte_rpctq_safe_inventories.quantity

FROMzte_rpct_onhand

WHEREsubinventory_id=:

zte_rpctq_safe_inventories.subinventory_id

ANDinventory_item_id=:

zte_rpctq_safe_inventories.inventory_item_id;

EXCEPTION

WHENNO_DATA_FOUNDTHEN

:

zte_rpctq_safe_inventories.quantity:

=NULL;

END;

例2:

FUNCTIONget_prod_config_cost（p_cutoff_dateINDATE,

p_product_idINNUMBER,

p_inventory_item_idINNUMBER）RETURNNUMBER;

【规则3-2】程序块要采用缩进风格编写，缩进的空格数为4个。

说明：

对于由开发工具自动生成的代码可以有不一致。

【规则3-3】相对独立的程序块之间、变量说明之后必须加空行。

说明：

空行起着分隔程序段落的作用。

适当的空行可以使程序的布局更加清晰

正例：

BEGIN

SELECTCOUNT（*）

INTONORMAL

FROMfnd_concurrent_requests

WHEREstatus_code='C';

SELECTCOUNT（*）

INTOwarning

FROMfnd_concurrent_requests

WHEREstatus_code='G';

SELECTCOUNT（*）

INTOerror

FROMfnd_concurrent_requests

WHEREstatus_code='E';

END;

反例：

如下例子不符合规范。

BEGIN

SELECTCOUNT（*）

INTONORMAL

FROMfnd_concurrent_requests

WHEREstatus_code='C';

SELECTCOUNT（*）

INTOwarning

FROMfnd_concurrent_requests

WHEREstatus_code='G';

SELECTCOUNT（*）

INTOerror

FROMfnd_concurrent_requests

WHEREstatus_code='E';

END;

〖规则3-4〗循环、判断等语句中若有较长的表达式或语句，则要进行适应的划分，长表达式要在低优先级操作符处划分新行，操作符放在新行之首。

正例：

IFNOTMRP_GLOBALS.Equal（l_x_flow_schedule_rec.alternate_bom_designator,

l_flow_schedule_rec.alternate_bom_designator）

THEN

x_alternate_bom_designator

:

=l_x_flow_schedule_rec.alternate_bom_designator;

ENDIF;

IFNOTMRP_GLOBALS.Equal（l_x_flow_schedule_rec.alternate_routing_desig,

l_flow_schedule_rec.alternate_routing_desig）

THEN

x_alternate_routing_desig

:

=l_x_flow_schedule_rec.alternate_routing_desig;

ENDIF;

【规则3-5】函数、过程、包声明时，参数类型和参数名不允许分行书写。

依照美观易懂原则，参数比较多时，可以换行。

正例：

PROCEDUREget_next_handle（itemtypeINVARCHAR2,

itemkeyINVARCHAR2,

actidINNUMBER,

funcmodeINVARCHAR2,

resultoutOUTVARCHAR2）;

【规则3-6】不允许把多个短语句写在一行中，即一行只写一条语句。

正例：

l_pageNUMBER:

=1;

l_lineNUMBER:

=0;

反例：

l_pageNUMBER:

=1;l_lineNUMBER:

=0;

【规则3-7】宣示格式DECLARE、BEGIN、EXCEPTION和END语句总是独占一行。

正例：

DECLARE

…;

BEGIN

…;

EXCEPTION

WHENOTHERSTHEN

NULL;

END;

【规则3-8】对齐只使用空格键，不使用TAB键。

说明：

以免用不同的编辑器阅读程序时，因TAB键所设置的空格数目不同而造成程序布局不整齐。

【规则3-9】在开始括号“（”与下一个字符之间不允许插入空格，同样，在结束括号“）”与前一个字符之间也不允许插入空格

正例：

Clear_Block（NO_COMMIT）;//正确

反例：

Clear_Block（NO_COMMIT）;//错误

4注释

注释的原则是有助于对程序的阅读理解，在该加的地方都加了，注释不宜太多也不能太少，注释语言必须准确、易懂、简洁。

【规则4-1】包头文件头部应进行注释，注释必须列出：

版权说明、版本号、创建日期、作者、内容、功能、与其它文件的关系、修改日志等，头文件的注释中还应有函数、过程功能简要说明。

正例：

/*+===========================================================================+

版权信息：

版权所有（C）2004，XXXX有限公司

文件名称：

版本号：

创建者：

创建日期：

内容摘要：

<说明此程序文件完成的主要功能，与其他模块或函数的接口，独立或依赖等关系。

>

功能列表：

主要函数、过程列表，每条记录应包括函数、过程名及功能简要说明

更新历史：

更新历史记录列表，每条修改记录应包括更新日期、更新者及更新内容简述

更新者更新日期更新内容

+===========================================================================+*/

【规则4-2】源文件（包括包体、触发器等）头部应进行注释，列出：

版权说明、版本号、创建日期、创建者、模块功能、主要函数及其功能、修改日志等。

正例：

/*+===========================================================================+

版权信息：

版权所有（C）2004，XXXX有限公司

文件名称：

创建者：

创建日期：

内容摘要：

项描述本文件的内容、功能、内部各部分之间的关系及本文件与其它文件关系等

功能列表：

主要函数、过程列表，每条记录应包括函数、过程名及功能简要说明（包体可忽略）

更新历史：

更新历史记录列表，每条修改记录应包括更新日期、更新者及更新内容简述

更新者更新日期更新内容

+===========================================================================+*/

【规则4-3】函数、过程头部应进行注释，列出：

函数的目的/功能、输入参数、输出参数、返回值、调用关系（函数、表）等。

正例：

/*+===========================================================================+

名称：

函数或存储过程名称

内容摘要：

函数或存储过程功能、性能等的描述

调用：

被本函数、过程调用的函数清单

被调用：

调用本函数、过程的函数清单

创建者：

被访问表：

被访问的表（此项仅对于牵扯到数据库操作的程序）

被更新表：

被修改的表（此项仅对于牵扯到数据库操作的程序）

输入：

输入参数说明，包括每个参数的作用、取值说明及参数间关系。

输出：

对输出参数的说明

返回值：

返回值的说明

其它：

其它说明

+===========================================================================+*/

【规则4-4】保证代码和注释的一致。

说明：

修改代码应同时修改相应的注释，不再有用的注释要删除

【规则4-5】注释的内容要清楚、明了，含义准确，防止注释二义性。

说明：

错误的注释不但无益反而有害。

【规则4-6】避免在注释中使用缩写，特别是非常用缩写。

说明：

在使用缩写时或之前，应对缩写进行必要的说明。

【规则4-7】注释应与其描述的代码相近，对代码的注释应放在其上方或右方（对单条语句的注释）相邻位置，不可放在下面，如放于上方则需与其上面的代码用空行隔开。

正例：

如下书写比较结构清晰

/*代码段1注释*/

[代码段1]

/*代码段2注释*/

[代码段2]

反例1：

如下例子注释与描述的代码相隔太远。

/*代码段注释*/

[代码段1]

反例2：

如下例子注释不应放在所描述的代码下面。

FUNCTIONgetQtyOeIssued（p_contract_line_idNUMBER）RETURNNUMBER;

PRAGMARESTRICT_REFERENCES（getQtyOeIssued,WNDS,WNPS）;

--获取OE发运数量

反例3：

如下例子，显得代码与注释过于紧凑。

/*代码段1注释*/

[代码段1]

/*代码段2注释*/

[代码段2]

【规则4-8】注释与所描述内容进行同样的缩排。

说明：

可使程序排版整齐，并方便注释的阅读与理解。

正例：

如下注释结构比较清晰

intDoSomething（void）

{

/*代码段1注释*/

[代码段1]

/*代码段2注释*/

[代码段2]

}

反例：

如下例子，排版不整齐，阅读不方便；

intDoSomething（void）

{

/*代码段1注释*/

[代码段1]

/*代码段2注释*/

[代码段2]

}

【规则4-8】对分支语句（条件分支、循环语句等）必须编写注释。

说明：

这些语句往往是程序实现某一特殊功能的关键，对于维护人员来说，良好的注释有助于更好的理解程序，有时甚至优于看设计文档。

〖规则4-9〗全局变量要有较详细的注释，包括对其功能、取值范围、哪些函数或过程存取它以及存取时注意事项等的说明。

正例：

/*变量作用、含义

变量取值范围

使用方法

*/

：

global.g_name=‘a’;

〖规则4-10〗在代码的功能、意图层次上进行注释，提供有用、额外的信息。

说明：

注释的目的是解释代码的目的、功能和采用的方法，提供代码以外的信息，帮助读者理解代码，防止没必要的重复注释信息。

正例：

如下的注释则给出了额外有用的信息

--如果库存组织是中兴通讯

ifx_main_flag=0then

反例：

如下注释意义不大

--如果x_main_flag是0

ifx_main_flag=0then

〖规则4-11〗在程序块的结束行右方加注释标记，以表明某程序块的结束。

说明：

当代码段较长，特别是多重嵌套时，这样做可以使代码更清晰，更便于阅读。

正例：

--循环程序段说明

FORr_batchINc_batchLOOP

l_batch_date:

=get_origin_abs_date（x_con_header_id,r_batch.batch_code）;

--外判断说明

IFl_batch_dateISNOTNULLTHEN

--内判断说明

IFl_abs_dateISNULLORl_abs_date

l_abs_date:

=l_batch_date;

ENDIF–指明哪个IF语句结束

ENDIF;--指明哪个IF语句结束

ENDLOOP;--指明循环结束

〖规则4-12〗注释应考虑程序易读及外观排版的因素，使用的语言若是中、英兼有的，建议多使用中文。

说明：

注释语言不统一，影响程序易读性和外观排版，出于对维护人员的考虑，建议使用中文。

〖规则4-13〗程序中关键的地方需增加注释，以提高程序的可读性。

说明：

在下列情况下必须有注释：

◆完整的功能模块前；

◆不易理解的代码；

◆对原有代码的修改

〖建议〗

◆注释行不得少于程序行的30%。

◆在超过三层以上的嵌套语句中，每一个嵌套后都应该加上注释，以表明和哪层的逻辑语句块对应。

◆单行注释应用“--”，避免使用“/**/”

5命名规则

好的命名规则能极大地增加可读性和可维护性。

同时，对于一个有上百个人共同完成的大项目来说，统一命名约定也是一项必不可少的内容。

本章对程序中的所有标识符（包括包名、变量名、常量名、控件名、参数名、属性名、函数名、过程名等）的命名做出约定。

【规则5-1】标识符的命名要清晰、明了，有明确含义，同时使用完整的单词或大家基本可以理解的缩写，避免使人产生误解。

说明：

较短的单词可通过去掉“元音”形成缩写，较长的单词可取单词的头几个字母形成缩写，一些单词有大家公认的缩写，常用单词的缩写必须统一。

协议中的单词的缩写与协议保持一致。

对于某个系统使用的专用缩写应该在某处做统一说明。

正例：

如下单词的缩写能够被大家基本认可。

temp可缩写为tmp；

flag可缩写为flg；

statistic可缩写为stat；

increment可缩写为inc；

message可缩写为msg；

规定的常用缩写如下：

常用词

缩写

Argument

Arg

Buffer

Buf

Clear

Clr

Clock

Clk

Compare

Cmp

Configuration

Cfg

Context

Ctx

Delay

Dly

Device

Dev

Disable

Dis

Display

Disp

Enable

En

Error

Err

Function

Fnct

Hexadecimal

Hex

HighPriorityTask

HPT

I/OSystem

IOS

Initialize

Init

Mailbox

Mbox

Manager

Mgr

Maximum

Max

Message

Msg

Minimum

Min

Multiplex

Mux

OperatingSystem

OS

Overflow

Ovf

Parameter

Param

Pointer

Ptr

Previous

Prev

Priority

Prio

Read

Rd

Ready

Rdy

Register

Reg

Schedule

Sched

Semaphore

Sem

Stack

Stk

Synchronize

Sync

Timer

Tmr

Trigger

Trig

Write

Wr

【规则5-2】自己特有的命名风格，要自始至终保持一致，不可来回变化。

说明：

个人的命名风格，在符合所在项目组或产品组的命名规则的前提下，才可使用。

（即命名规则中没有规定到的地方才可有个人命名风格）。

【规则5-3】一般变量名不得取单个字符（如i、j、k等）作为变量名，局部循环变量除外。

说明：

变量，尤其是局部变量，如果用单个字符表示，很容易出错（如l误写成1）,而编译时又检查不出，则有可能增加排错时间。

过长的变量名会增加工作量，会使程序的逻辑流程变得模糊，给修改带来困难，所以应当选择精炼、意义明确的名字，才能简化程序语句，改善对程序功能的理解。

对于嵌套的循环，一般最外层循环用i，第二层用j，依此类推

【规则5-4】采用应用领域相关的术语来命名。

说明：

软件开发人员应注意软件用户的一些约定术语，不应当随意的创造术语，这会降低软件的易用性。

【规则5-5】变量名使用全部采用小写。

【规则5-6】用正确的反义词组命名具有互斥意义的变量或相反动作的函数等。

说明：

下面是一些在软件中常用的反义词组。

add/remove；begin/end；create/destroy；insert/delete；

first/last；get/release；increment/decrement；put/get；

add/delete；lock/unlock；open/close；min/max；

old/new；start/stop；next/previous；source/target；

show/hide；send/receive；source/destination；cut/paste；

up/down

【规则5-7】常量名都要使用大写字母,用下划线‘_’分割单词。

正例：

如DISP_BUF_SIZE、MIN_VALUE、MAX_VALUE等等。

【规则5-8】变量名一般以代表该变量类型的小写前缀加”_”开头。

说明：

常用类型前缀列表如下：

i_：

INTEGER

n_：

NUMBER

v_：

VARCHAR2

b_：

BOOLEAN

以上前缀可以进一步组合成新的类型，自定义的数据类型可以自己规定类型前缀，如果该类型使用较为广泛，可以升级为公司内部的通用前缀

【规则5-9】标识符只能由26个英文字母，10个数字，及下划线的一个子集来组成，并严格禁止使用连续的下划线，下划线也不能出现在标识符头或结尾。

说明：

这样做的目的是为了使程序易读。

因为variable_name和variable__name很难区分，下划线符号‘_’若出现在标识符头或结尾，容易与不带下划线‘_’的标识符混淆。

【规则5-10】标识符要采用英文单词或其组合，便于忆和阅读，切忌使用汉语拼音来命名。

说明：

标识符应当直观且可以拼读，可望文知义，避免使人产生误解。

程序中的英文单词一般不要太复杂，用词应当准确

【规则5-11】尽量避免名字中出现数字编号，如Value1、Value2等，除非逻辑上的确需要编号。

说明：

前缀为变量类型前缀。

【规则5-12】若类型名为Oracle保留字，则必须全部大写。

自定义的类型，采用全部小写。

正例：