欢迎光临Software MyZone,有问题可留言或到站点论坛发帖,争取第一时间帮忙解决 || 站点论坛:火龙论坛 || 淘宝小店:应小心的易淘屋 【欢迎大家提建设性意见】

c++规范

(一)文件结构:
(1)头文件:

所有C++的源文件均必须包含一个规范的文件头,文件头包含了该文件的名称、功能概述、作者、版权和版本历史信息等内容。标准文件头的格式为:
/*! @file
********************************************************************************
<PRE>
模块名 : <文件所属的模块名称>
文件名 : <文件名>
相关文件 : <与此文件相关的其它文件>
文件实现功能 : <描述该文件实现的主要功能>
作者 : <作者部门和姓名>
版本 : <当前版本号>
——————————————————————————–
多线程安全性 : <是/否>[,说明]
异常时安全性 : <是/否>[,说明]
——————————————————————————–
备注 : <其它说明>
——————————————————————————–
修改记录 :
日 期 版本 修改人 修改内容
YYYY/MM/DD X.Y <作者或修改者名> <修改内容>
</PRE>
*******************************************************************************/
如果该文件有其它需要说明的地方,还可以专门为此扩展一节,节与节之间用长度为80的“=”带分割:

/*! @file
********************************************************************************
<PRE>
模块名 : <文件所属的模块名称>
文件名 : <文件名>
相关文件 : <与此文件相关的其它文件>
文件实现功能 : <描述该文件实现的主要功能>
作者 : <作者部门和姓名>
版本 : <当前版本号>
——————————————————————————–
多线程安全性 : <是/否>[,说明]
异常时安全性 : <是/否>[,说明]
——————————————————————————–
备注 : <其它说明>
——————————————————————————–
修改记录 :
日 期 版本 修改人 修改内容
YYYY/MM/DD X.Y <作者或修改者名> <修改内容>
</PRE>
********************************************************************************

* 项目1
- 项目1.1
- 项目1.2

================================================================================
* 项目2
- 项目2.1
- 项目2.2
….

*******************************************************************************/

(二)函数

函数的命名 函数的名称由一个或多个单词组成。为便于界定,每个单词的首字母要大写。
推荐的组成形式 函数名应当使用”动词”或者”动词+名词”(动宾词组)的形式。例如:”GetName()”, “SetValue()”, “Erase()”, “Reserve()” ….
保护成员函数 保护成员函数的开头应当加上一个下划线“_”以示区别,例如:”_SetState()” ….
私有成员函数 类似地,私有成员函数的开头应当加上两个下划线“__”,例如:”__DestroyImp()” ….
私有成员函数的层次结构表示 通常来说,在一个类中,公有方法、保护方法和私有方法所完成的任务总是呈现一种逐级依次细化的层次结构(意即:保护方法所实现的功能通常比该类中的公有方法更为细小琐碎;类似地,私有方法的功能也比其保护方法更具原子性)。
因此,对于遵循以上规则,并且功能较为复杂的类,在按照“公有、保护、私有”的三级形式划分以后,如果其私有成员中仍然存在明显不同的功能粒度,则可以通过追加更多下划线前缀的形式予以表示。

例如:由三个下划线开头的私有方法“___PushCdr”就要比同一类中,仅由两个下划线开头的私有方法“__MergeConCall”所完成的功能粒度更细小、更琐碎;而四个下划线开头的“____CalcCompensate”则比“___PushCdr”完成的功能 更具原子性。

如果发现类中的功能层数太多(从公有方法到最“原子”的私有方法间,一般不应该超过 7 层),那通常反应一个不良的设计。此时请检查这个类的功能是否过于臃肿,已使接口显得不太清晰。另外一个常见的问题是将无需访问该类中 私有或保护成员的功能定义成了方法。第一个问题可以通过重新划分类层次结构或将一个类分裂为多个类等方法解决。对于第二个问题,由于这些方法无需访问 受限成员,大多数时候都可以把它们转变成局部函数(放在无名空间或使用“static”前缀定义)。

成员函数的下划线后缀命名 对一些本应该作为保护或私有成员的函数,由于设计方面的其它考虑(例如:灵活性、功能等方面)将其提升为公有成员的,应该在其后面添加与其原本访问控制级别相应的下划线后缀。
另外,对于其它不推荐直接使用的成员函数(例如:会引起兼容性或可移植性方面问题的函数),也应当在其后面加相应下划线提示。

例如:”ioctl_()”, “SetSysOpt_()”, “GetSysOpt_()”, “PreParser__()” ….

回调和事件处理函数 回调和事件处理函数习惯以单词“On”开头。例如:”_OnTimer()”, “OnExit()” ….
虚函数 回调函数以外的虚函数习惯以“Do”开头,如:”DoRefresh()”, “_DoEncryption()” ….

(三)变量
变量应该是程序中使用最多的标识符了,变量的命名规范可能是一套C++命名准则中最重要的部分:

变量的命名 变量名由作用域前缀+类型前缀+一个或多个单词组成。为便于界定,每个单词的首字母要大写。
对于某些用途简单明了的局部变量,也可以使用简化的方式,如:i, j, k, x, y, z ….

作用域前缀 作用域前缀标明一个变量的可见范围。作用域可以有如下几种:
前缀 说明
无 局部变量
m_ 类的成员变量(member)
sm_ 类的静态成员变量(static member)
s_ 静态变量(static)
g_ 外部全局变量(global)
sg_ 静态全局变量(static global)
gg_ 进程或动态链接库间共享的全局变量(global global)
除非不得已,否则应该尽可能少使用全局变量。

关于全局变量和局部静态变量的依赖性问题和初始化时的线程安全性问题,请参考:多处理器环境和线程同步的高级话题 一节

类型前缀 类型前缀标明一个变量的类型,可以有如下几种:
前缀 说明
n 整型和位域变量(number)
e 枚举型变量(enumeration)
c 字符型变量(char)
b 布尔型变量(bool)
f 浮点型变量(float)
p 指针型变量和迭代子(pointer)
pfn 指向函数的指针变量或指向函数对象的指针(pointer of function)
pm 指向成员的指针(pointer of member)
r 引用(reference),此前缀对于常引用(const reference)来说可以省略
g 数组(grid)
fo 函数对象(Function Object)
i 类的实例(instance)
对于经常用到的类,也可以定义一些专门的前缀,如:std::string和std::wstring类的前缀可以定义为”st”,std::vector类的前缀可以定义为”v”等等。

类型前缀可以组合使用,例如”gc”表示字符数组,”ppn”表示指向整型的指针的指针等等。

数值前缀的特别记法 以“n”作为所有整形前缀是由于大多数情况下,编写程序时不需要过多考虑整形的宽度,但在某些场合中,整形宽度是需要特别注意并且仔细加以区分的,这时可使用如下记法代替“n”前缀:
前缀 说明
b 字节(8bit,byte)
w 字(16bit,word)
dw 双字(32bit,double word)
qw -或- nn 四字(64bit,quad word)
bf 位域(bit field)
对浮点型变量也有类似记法如下:

前缀 说明
f 单精度浮点(32bit,float)
d 双精度浮点(64bit,double)
ld 扩展精度浮点(80bit,long double)
推荐的组成形式 变量的名字应当使用”名词”或者”形容词+名词”。例如:”nCode”, “m_nState”,”nMaxWidth” ….

(四)常量
C++中引入了对常量的支持,常量的命名规则如下:

常量的命名 常量名由类型前缀+全大写字母组成,单词间通过下划线来界定,如:cDELIMITER, nMAX_BUFFER ….
类型前缀的定义与变量命名规则 中的相同。

(五)宏、枚举值

宏、枚举值的命名 宏和枚举值由全大写字母组成,单词间通过下划线来界定,如:ERROR_UNKNOWN, OP_STOP ….

(六)名空间
C++名空间是“类”概念的一种退化(大体相当于只包含静态成员且不能实例化的类)。它的引入为标识符名称提供了更好的层次结构,使标识符看起来更加直观简捷,同时大大降低了名字冲突的可能性。
名空间的命名规则包括:

名空间的命名 名空间的名称不应该过长,通常都使用缩写的形式来命名。
例如,一个图形库可以将其所有外部接口存放在名空间”GLIB”中,但是将其换成”GRAPHIC_LIBRARY”就不大合适。

如果碰到较长的名空间,为了简化程序书写,可以使用:

namespace new_name = old_long_name;
语句为其定义一个较短的别名。

 

摘自:http://baiy.cn/doc/cpp/

Tags:

发表评论