最近一直在处理之前他人留下的代码,很是头疼。因为程序注释性的东西太少了,而且很多不合规范。不过也暴露了自己平时写代码的缺陷。在这里整理了一下程序注释编写规范,留待日后参考。

这儿有一篇来之http://chenyuangui.spaces.eepw.com.cn/articles/article/item/65556#

一、注释
程序中的注释能够帮助理解程序。但是也不能太多,太多同样会影响程序的可读性。要遵循简练,准确,易理解的原则。

1、文件头:文件的头部应该有个对本文件的详细描述。内容包括版权,版本号,生成日期,作者,内容,功能,函数功能,与其他文件的关系,修改日志等。尤其是每次修改,都应该写入修改日志。

下面是一个常用的模版
/*************************************************
Copyright (C), 2000-2004, ******
File name:      // 文件名
Author:       Version:        Date: // 作者、版本及完成日期
Description:    // 用于详细说明此程序文件完成的主要功能,与其他模块
// 或函数的接口,输出值、取值范围、含义及参数间的控
// 制、顺序、独立或依赖等关系
Others:         // 其它内容的说明
Function List:  // 主要函数列表,每条记录应包括函数名及功能简要说明
1. ….
History:        // 修改历史记录列表,每条修改记录应包括修改日期、修改
// 者及修改内容简述
1. Date:
Author:
Modification:
2. …
*************************************************/

2、函数:列出函数的目的,功能、输入输出、返回值、调用关系等。
模版:
/*************************************************
Function:       // 函数名称
Description:    // 函数功能、性能等的描述
Calls:          // 被本函数调用的函数清单
Called By:      // 调用本函数的函数清单
Table Accessed: // 被访问的表(此项仅对于牵扯到数据库操作的程序)
Table Updated:  // 被修改的表(此项仅对于牵扯到数据库操作的程序)
Input:          // 输入参数说明,包括每个参数的作
// 用、取值说明及参数间关系。
Output:         // 对输出参数的说明。
Return:         // 函数返回值的说明
Others:         // 其它说明
*************************************************/

3、文件内部注释:编写代码的同时应该写出注释,修改代码时应该连同修改注释。保证注释与文件的同步。写注释时应该遵循简洁,准确,明了的原则,尽 量少使 用缩写,尤其是不常用的缩写。注释的位置应该在被注释语句的上方或右方,位于上方时,应该与上方的语句用空行分开。注释应该与被注释语句相同缩进。

4、命名:变量,数据结构等如果命名不是充分自注释的,必须有注释。说明其作用,取值范围,在哪里使用,适用时的注意事项等。

5、语句:分支语句必须给出注释。包括语句块的功能,输出。程序块结束行右方必须给出注释以表明程序块结束。switch语句由于某种情况在一个case结束后必须进入另一个case语句时,必须加上注释。

6、其他需要注意的事项:应该避免在一行代码或表达式中使用注释;函数,变量,结构等的命名尽量遵循规范,使代码成为自注释的;注释应该是对代码的解释或对意图的说明,帮助理解代码。
二、排版

正确的排版方式有助于程序的理解,增加可读性。并且在编写代码的过程中,有助于梳理思路。

1、程序块必须采用缩进风格编写,最好是缩进4个空格。最好不用使用“tab”键,不同的编辑器对“tab”的解释方式不同,容易造成混乱。

2、相对独立的程序块之间、变量说明之后必须加空行。

3、较长的语句应该换行。尽量在低优先级的操作符出换行。换行要有必要缩进,并把操作符放在此行最前面。如果是函数的参数,则不允许将某一参数隔断,应该在两个参数之间换行,中间的逗号放在上一行的最后,

4、if、for、do、while、case、switch、default等语句自占一行,且if、for、do、while等语句的执行语句部分无论多少都要加括号{}。括号(程序块的分界符)也独占一行,不缩进,其内语句才开始缩进。

5、多个短句不允许放在同一行。

6、在两个以上的关键字、变量、常量进行对等操作时,它们之间的操作符之前、之后或者前后要加空格;进行非对等操作时,如果是关系密切的立即操作符(如->),后不应加空格。

三、 标识符命名
1、标识符的命名要清晰、明了,有明确含义,同时使用完整的单词或大家基本可以理解的缩写,避免使人产生误解。
说明:较短的单词可通过去掉“元音”形成缩写;较长的单词可取单词的头几个字母形成缩写;一些单词有大家公认的缩写。
示例:如下单词的缩写能够被大家基本认可。
temp      可缩写为  tmp  ;
flag      可缩写为  flg  ;
statistic 可缩写为  stat ;
increment 可缩写为  inc  ;
message   可缩写为  msg  ;

2、命名中若使用特殊约定或缩写,则要有注释说明。
说明:应该在源文件的开始之处,对文件中所使用的缩写或约定,特别是特殊的缩写,进行必要的注释说明。

3、自己特有的命名风格,要自始至终保持一致,不可来回变化。
说明:个人的命名风格,在符合所在项目组或产品组的命名规则的前提下,才可使用。(即命名规则中没有规定到的地方才可有个人命名风格)。

4、对于变量命名,禁止取单个字符(如i、j、k…),建议除了要有具体含义外,还能表明其变量类型、数据类型等,但i、j、k作局部循环变量是允许的。
说明:变量,尤其是局部变量,如果用单个字符表示,很容易敲错(如i写成j),而编译时又检查不出来,有可能为了这个小小的错误而花费大量的查错时间。
示例:下面所示的局部变量名的定义方法可以借鉴。
int liv_Width
其变量名解释如下:
l      局部变量(Local)  (其它:g    全局变量(Global)…)
i      数据类型(Interger)
v      变量(Variable)   (其它:c    常量(Const)…)
Width  变量含义
这样可以防止局部变量与全局变量重名。

5、命名规范必须与所使用的系统风格保持一致,并在同一项目中统一,比如采用UNIX的全小写加下划线的风格或大小写混排的方式,不要使用大小写与下划线混排的方式,用作特殊标识如标识成员变量或全局变量的m_和g_,其后加上大小写混排的方式是允许的。
示例: Add_User不允许,add_user、AddUser、m_AddUser允许。

6、:除非必要,不要用数字或较奇怪的字符来定义标识符。
示例:如下命名,使人产生疑惑。
#define _EXAMPLE_0_TEST_
#define _EXAMPLE_1_TEST_
void set_sls00( BYTE sls );

应改为有意义的单词命名
#define _EXAMPLE_UNIT_TEST_
#define _EXAMPLE_ASSERT_TEST_
void set_udt_msg_sls( BYTE sls );

7、在同一软件产品内,应规划好接口部分标识符(变量、结构、函数及常量)的命名,防止编译、链接时产生冲突。
说明:对接口部分的标识符应该有更严格限制,防止冲突。如可规定接口部分的变量与常量之前加上“模块”标识等。

8、用正确的反义词组命名具有互斥意义的变量或相反动作的函数等。

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
示例:
int  min_sum;
int  max_sum;
int  add_user( BYTE *user_name );
int  delete_user( BYTE *user_name );

9、除了编译开关/头文件等特殊应用,应避免使用_EXAMPLE_TEST_之类以下划线开始和结尾的定义

标签:
本文连接地址: http://www.fresker.com/old2/archives/264 (转载注明出处)

回复

目前暂无评论

Sorry, 评论已关闭.