HHIC verification coding stylev013.docx
《HHIC verification coding stylev013.docx》由会员分享，可在线阅读，更多相关《HHIC verification coding stylev013.docx（22页珍藏版）》请在冰点文库上搜索。
HHICverificationcodingstylev013
HHICVERIFICATIONCONDINGSTYLE
Version:
0.1
RevisionHistory
Version
EditingNote
Owner/Date
Confirm/Date
Approved/Date
ImplementDate
V0.1
初稿
赵治心
10-07-20
Contents
1.Typeset6
1.1【规则】代码块要采用缩进风格编写，缩进的空格数为4个。
6
1.2【建议】相对独立的代码块之间必须加空行。
6
1.3【规则】较长的语句（>80字符）要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐，语句可读。
6
1.4【建议】循环、判断等语句中若有较长的表达式或语句，则要进行适应的划分，长表达式要在低优先级操作符处划分新行，操作符放在新行之首。
7
1.5【建议】若函数或过程中的参数较长，则要进行适当的划分。
7
1.6【规则】不允许把多个短语句写在一行中，即一行只写一条语句。
7
1.7【规则】if、for、do、while、case、switch、default等语句自占一行，且if、for、do、while等语句的执行语句部分无论多少都要加beginend。
8
1.8【规则】函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风格，case语句下的情况处理语句也要遵从语句缩进要求。
8
1.9【规则】程序块的分界符（beginend）应各独占一行并且位于同一列，同时与引用它们的语句左对齐。
在函数体的开始、任务体的开始、类的定义、结构的定义、枚举的定义以及if、for、do、while、switch、case语句中的程序都要采用如上的缩进方式。
8
1.10【规则】在两个以上的关键字、变量、常量进行对等操作时，它们之间的操作符之前、之后或者前后要加空格；进行非对等操作时，如果是关系密切的立即操作符（如.），后不应加空格。
9
1.11【规则】变量的定义一行定义一个，不建议一行定义多个变量（成员）。
10
1.12【建议】函数体或者任务体定义时，一个参数对应一行，如果只有一个参数则与（）同一行即可。
10
1.13【建议】class的task或者function，在class实体内做声明，定义则在class实体外。
11
2.Remark12
2.1【规则】一般情况下，源程序有效注释量必须在20％以上。
12
2.2【规则】每个文件必须有头文件。
12
2.3【建议】任务（函数）头部应进行注释，描述任务（函数）的主要功能。
13
2.4【规则】注释的内容要清楚、明了，含义准确，防止注释二义性。
13
2.5【规则】注释应与其描述的代码相近，对代码的注释应放在其上方或右方（对单条语句的注释）相邻位置，不可放在下面。
13
2.6【规则】对于所有有物理含义的变量、常量，如果其命名不是充分自注释的，在声明时都必须加以注释，说明其物理含义。
变量、常量、宏的注释应放在其上方相邻位置或右方。
13
2.7【规则】类声明（包括数组、结构、枚举等），如果其命名不是充分自注释的，必须加以注释。
对类的注释应放在其上方相邻位置，不可放在下面；对类中的每个成员的注释放在此类的右方。
13
2.8【规则】注释与所描述内容进行同样的缩排。
14
2.9【建议】将注释与其上面的代码用空行隔开。
15
2.10【规则】对变量的定义和分支语句（条件分支、循环语句等）必须编写注释。
15
2.11【规则】对于switch语句下的case语句，必须用begin…end包含该case语句的处理代码。
15
2.12【规则】避免在一行代码或表达式的中间插入注释。
16
2.13【建议】通过对函数或过程、变量、结构等正确的命名以及合理地组织代码的结构，使代码成为自注释的。
16
2.14【建议】在代码的功能、意图层次上进行注释，提供有用、额外的信息。
16
2.15【建议】注释格式尽量统一，建议使用“//”。
16
3.Identifier16
3.1【规则】标识符的命名要清晰、明了，有明确含义，同时使用完整的单词或大家基本可以理解的缩写，避免使人产生误解。
16
3.2【规则】命名中若使用特殊约定或缩写，则要有注释说明。
17
3.3【规则】对于变量命名，禁止取单个字符（如i、j、k...），建议除了要有具体含义外，还能表明其变量类型、数据类型等，但i、j、k作局部循环变量是允许的。
17
3.4【规则】命名规范必须与所使用的系统风格保持一致，并在同一项目中统一，比如采用UNIX的全小写加下划线的风格或大小写混排的方式，不要使用大小写与下划线混排的方式。
17
3.5【规则】除非必要，不要用数字或较奇怪的字符来定义标识符。
17
3.6【规则】用正确的反义词组命名具有互斥意义的变量或相反动作的函数等。
18
3.7【规则】除了编译开关/头文件等特殊应用，应避免使用_EXAMPLE_TEST_之类以下划线开始和结尾的定义。
18
4.Readability18
4.1【规则】注意运算符的优先级，并用括号明确表达式的操作顺序，避免使用默认优先级。
18
4.2【建议】避免使用不易理解的数字，用有意义的标识来替代。
涉及物理状态或者含有物理意义的常量，不应直接使用数字，必须用有意义的枚举或宏来代替。
19
4.3【建议】源程序中关系较为紧密的代码应尽可能相邻。
19
4.4【建议】不要使用难懂的技巧性很高的语句，除非很有必要时。
20
5.Task&Function20
5.1【规则】对所调用任务/函数的错误返回码要仔细、全面地处理。
20
5.2【规则】明确任务/函数功能，精确（而不是近似）地实现函数设计。
20
5.3【规则】一个函数仅完成一件功能。
20
5.4【建议】为简单功能编写函数。
20
5.5【建议】不要设计多用途面面俱到的任务/函数。
21
5.6【建议】任务/函数的功能应该是可以预测的，也就是只要输入数据相同就应产生同样的输出。
21
5.7【规则】避免设计多参数任务/函数，不使用的参数从接口中去掉。
21
5.8【建议】检查任务/函数所有参数输入的有效性。
21
5.9【建议】使用动宾词组为执行某操作的任务/函数命名。
21
5.10【建议】让任务/函数在调用点显得易懂、容易理解。
21
5.11【建议】避免任务/函数中不必要语句，防止程序中的垃圾代码。
21
5.12【规则】防止把没有关联的语句放到一个任务/函数中。
22
5.13【建议】如果多段代码重复做同一件事情，那么在任务/函数的划分上可能存在问题。
23
5.14【建议】功能不明确较小的任务/函数，特别是仅有一个上级任务/函数调用它时，应考虑把它合并到上级任务/函数中，而不必单独存在。
23
5.15【建议】设计高扇入、合理扇出（小于7）的任务/函数。
23
5.16【建议】减少任务/函数本身或任务/函数间的递归调用。
23
6.CodeQuality24
6.1【规则】系统运行之初，要初始化有关变量及运行环境，防止未经初始化的变量被引用。
24
6.2【规则】编程时，要防止差1错误。
24
6.3【规则】要时刻注意易混淆的操作符。
当编完程序后，应从头至尾检查一遍这些操作符，以防止拼写错误。
。
24
6.4【建议】有可能的话，if语句尽量加上else分支，对没有else分支的语句要小心对待；switch语句必须有default分支。
24
6.5【规则】时刻注意表达式是否会上溢、下溢。
24
6.6【规则】使用变量时要注意其边界值的情况。
25
1.
Typeset
1.1【规则】代码块要采用缩进风格编写，缩进的空格数为4个。
说明：
对于由开发工具自动生成的代码可以有不一致。
采用空格缩进的好处是不同编辑器打开文件时缩进都一致，使用TAB则会存在默认空格数不一致的问题，编辑代码时可以将编辑器的TAB键扩展设置为用4个空格代替，这样就可以使用TAB键来做缩进。
1.2【建议】相对独立的代码块之间必须加空行。
示例：
如下例子不符合规范。
if（!
valid_ni（ni））
begin
...//programcode
end
repssn_ind=ssn_data.repssn_index;
repssn_ni=ssn_data.ni;
应如下书写
if（!
valid_ni（ni））
begin
...//programcode
end
repssn_ind=ssn_data.repssn_index;
repssn_ni=ssn_data.ni;
1.3【规则】较长的语句（>80字符）要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐，语句可读。
示例：
report_or_not_flag=（（taskno&&（n7stat_stat_item_valid（stat_item））
&&（act_task_table[taskno].result_data!
=0））;
1.4【建议】循环、判断等语句中若有较长的表达式或语句，则要进行适应的划分，长表达式要在低优先级操作符处划分新行，操作符放在新行之首。
示例：
if（（taskno&&（n7stat_stat_item_valid（stat_item）））
begin
...//programcode
end
for（i=0,j=0;（i&&（jbegin
...//programcode
end
1.5【建议】若函数或过程中的参数较长，则要进行适当的划分。
示例：
n7stat_flash_act_duration（stat_item,frame_id*STAT_TASK_CHECK_NUMBER
+index,stat_object）;
1.6【规则】不允许把多个短语句写在一行中，即一行只写一条语句。
示例：
如下例子不符合规范。
intlength=0;width=0;
应如下书写
intlength=0;
intwidth=0;
1.7【规则】if、for、do、while、case、switch、default等语句自占一行，且if、for、do、while等语句的执行语句部分无论多少都要加beginend。
示例：
如下例子不符合规范。
if（user_cr==NULL）return;
应如下书写：
if（user_cr==NULL）
begin
return;
end
1.8【规则】函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风格，case语句下的情况处理语句也要遵从语句缩进要求。
1.9【规则】程序块的分界符（beginend）应各独占一行并且位于同一列，同时与引用它们的语句左对齐。
在函数体的开始、任务体的开始、类的定义、结构的定义、枚举的定义以及if、for、do、while、switch、case语句中的程序都要采用如上的缩进方式。
示例：
如下例子不符合规范。
for（...）begin
...//programcode
end
if（...）
begin
...//programcode
end
voidfunctionexample_fun（void）
begin
...//programcode
end
应如下书写：
for（...）
begin
...//programcode
end
if（...）
begin
...//programcode
end
voidfunctionexample_fun（void）
begin
...//programcode
end
注意：
使用fork…join时不使用begin…end做分界，VCS会将fork之后的begin…end作为一个线程来解释。
1.10【规则】在两个以上的关键字、变量、常量进行对等操作时，它们之间的操作符之前、之后或者前后要加空格；进行非对等操作时，如果是关系密切的立即操作符（如.），后不应加空格。
说明：
采用这种松散方式编写代码的目的是使代码更加清晰。
由于留空格所产生的清晰性是相对的，所以，在已经非常清晰的语句中没有必要再留空格，括号内侧建议加空格，多重括号间不必加空格。
在长语句中，如果需要加的空格非常多，那么应该保持整体清晰，而在局部不加空格。
给操作符留空格时不要连续留两个以上空格。
示例：
（1）逗号、分号只在后面加空格。
$display（“%h,%h,%h”,a,b,c）;
（2）比较操作符,赋值操作符"="、"+="，算术操作符"+"、"%"，逻辑操作符"&&"、"&"，位域操作符"<<"、"^"等双目操作符的前后加空格。
if（current_time>=MAX_TIME_VALUE）
a=b+c;
a*=2;
a=b^2;
（3）"!
"、"~"、"++"、"--"等单目操作符前后不加空格。
p='a';//内容操作"*"与内容之间
flag=!
isEmpty;//非操作"!
"与内容之间
i++;//"++","--"与内容之间
（4）"."前后不加空格。
this.id=pid;//"."前后不加空格
（5）括号内侧建议加空格，多重括号间不加空格。
if（a>=b&&c>d）
if（（a>=b）&&（c>d））
1.11【规则】变量的定义一行定义一个，不建议一行定义多个变量（成员）。
示例：
如下例子不符合规范。
single_packetpkt_send,pkt_rev,send_temp;
应如下书写：
single_packetpkt_send;
single_packetpkt_rev;
single_packetsend_temp;
1.12【建议】函数体或者任务体定义时，一个参数对应一行，如果只有一个参数则与（）同一行即可。
示例：
如下例子不符合规范。
functionnew（stringinstance=“class”,swp_subenv_cfgcfg,
packet_swp_channelin_swp_chan,packet_swp_channelin_apb_chan,single_packet_channelout_dut_chan,single_packet_channelin_dut_chan,scoreboardsb,vmm_ral_accessral,vmm_notifynotify）;
应如下书写：
functionnew（
stringinstance=“class”,
swp_subenv_cfgcfg,
packet_swp_channelin_swp_chan,
packet_swp_channelin_apb_chan,
single_packet_channelout_dut_chan,
single_packet_channelin_dut_chan,
scoreboardsb,
vmm_ral_accessral,
vmm_notifynotify
）;
functionnew（stringinstance）;
1.13【建议】class的task或者function，在class实体内做声明，定义则在class实体外。
说明：
采用extern方式声明task/function使class更清晰。
classscoreboardextendsvmm_xactor;
……
externfunctionnew（stringinstance,swp_subenv_cfgcfg）;
externvirtualprotectedtaskmain（）;
externvirtualfunctionvoidswpmansendpkt（single_packetpkt）;
externvirtualfunctionvoidAPBmanreceivepkt（single_packetpkt）;
externvirtualfunctionvoidswpmanreceivepkt（single_packetpkt）;
externvirtualfunctionvoidAPBmansendpkt（single_packetpkt）;
endclass:
scoreboard
2.Remark
2.1【规则】一般情况下，源程序有效注释量必须在20％以上。
说明：
注释的原则是有助于对程序的阅读理解，在该加的地方都加了，注释不宜太多也不能太少，注释语言必须准确、易懂、简洁。
2.2【规则】每个文件必须有头文件。
/*************************************************************/
/*copyright2008,HHIC*/
/*allrightreserved*/
/**/
/*projectname:
HD_SIM*/
/*filename:
cpu_gen.sv*/
/*author:
zhaozhixin*/
/*data:
2008/12/29*/
/*version:
1.0*/
/*abstract:
realizationgenmoudleofcpu*/
/**/
/*modificationhistory*/
/*-----------------------------------------------------------*/
/*|name|modify|data|version|*/
/*-----------------------------------------------------------*/
/*|zhaozhixin|init|2008/12/29|v1.0|*/
/*-----------------------------------------------------------*/
/*|||||*/
/*---------------------------------------------------------*/
/*|||||*/
/*-----------------------------------------------------------*/
/**************************************************************/
//$log:
cpu_gen.sv
2.3【建议】任务（函数）头部应进行注释，描述任务（函数）的主要功能。
2.4【规则】注释的内容要清楚、明了，含义准确，防止注释二义性。
说明：
错误的注释不但无益反而有害。
2.5【规则】注释应与其描述的代码相近，对代码的注释应放在其上方或右方（对单条语句的注释）相邻位置，不可放在下面。
//getreplicatesubsystemindexandnetindicator
repssn_ind=ssn_data[index].repssn_index;
repssn_ni=ssn_data[index].ni;
2.6【规则】对于所有有物理含义的变量、常量，如果其命名不是充分自注释的，在声明时都必须加以注释，说明其物理含义。
变量、常量、宏的注释应放在其上方相邻位置或右方。
示例：
//activestatistictasknumber
#defineMAX_ACT_TASK_NUMBER1000
#defineMAX_ACT_TASK_NUMBER1000//activestatistictasknumber
2.7【规则】类声明（包括数组、结构、枚举等），如果其命名不是充分自注释的，必须加以注释。
对类的注释应放在其上方相邻位置，不可放在下面；对类中的每个成员的注释放在此类的右方。
示例：
可按如下形式说明枚举、类结构。
//sccpinterfacewithsccpuserprimitivemessagename*/
enumSCCP_USER_PRIMITIVE
{
N_UNITDATA_IND,//sccpnotifysccpuserunitdatacome
N_NOTICE_IND,//sccpnotifyusertheNo.7networkcan//nottransmissionthismessage
N_UNITDATA_REQ,//sccpuser'sunitdatatransmission
//request
};
2.8【规则】注释与所描述内容进行同样的缩排。
说明：
可使程序排版整齐，并方便注释的阅读与理解。
示例：
如下例子，排版不整齐，阅读稍感不方便。
voidexample_fun（void）
begin
//codeonecomments
CodeBlockOne
//codetwocomments
CodeBlockTwo
end
应改为如下布局。
voidexample_fun（void）
begin
//codeonecomments
CodeBlockOne
//codetwocomments
CodeBlockTwo
end
2.9【建议】将注释与其上面的代码用空行隔开。
示例：
如下例子，显得代码过于紧
升级会员 