BCB命名规范

BCB命名规范  [转贴文档]
作者: snowblue (  snowblue )

1．源程序文件组织：每个程序文件单元通常都应由 .h 文件和 .cpp 文件组成，并将单元的公
共声明部分放在 .h 文件中。划分单元主要是以类为依据，原则上每个较大的类都应为一个单独的
单元，但在类较小且多个小类关系密切等情况下也可几个类共一个单元（建议仅对已经详细测试的
较为通用的类采用）。
2．源程序文件结构：每个程序文件应由标题、内容和附加说明三部分组成。
（1）标题：文件最前面的注释说明，其内容主要包括：程序名，作者，版权信息，简要说明
等，必要时应有更详尽的说明（将以此部分以空行隔开单独注释）。
（2）内容：为文件源代码部分基本上按预处理语句、类型定义、变量定义、函数原型、函数
实现（仅对 .cpp 文件）的顺序。 main 、 winmain ，控件注册等函数应放在内容部分的最后，类
的定义按 private 、 protected 、 pubilic 、 __pubished 的顺序，并尽量保持每一部分只有一
个，各部分中按数据、函数、属性、事件的顺序。
（3）附加说明：文件末尾的补充说明，如参考资料等，若内容不多也可放在标题部分的最
后。
3．编辑风格：
（1）缩进：缩进以 Tab 为单位，一个 Tab 为四个空格大小。预处理语句、全局数据、函数
原型、标题、附加说明、函数说明、标号等均顶格书写。语句块的“{”“}”配对对齐，并与其前
一行对齐，语句块类的语句缩进建议每个“{”“}”单独占一行。
（2）空格：数据和函数在其类型，修饰（如 __fastcall 等）名称之间适当空格并据情况对
齐。关键字原则上空一格，如： if ( ... ) 等，运算符的空格规定如下：“::”、“->”、
“[”、“]”、“++”、“--”、“~”、“!”、“+”、“-”（指正负号），“&”（取址或引
用）、“*”（指使用指针时）等几个运算符两边不空格（其中单目运算符系指与作数相连的一
边），其它运算符（包括大多数二目运算符和三目运算符“?:”两边均空一格，“(”、“)”运算
符在其内侧空一格，在作函数定义时还可据情况多空或不空格来对齐，但在函数实现时可以不用。
“,”运算符只在其后空一格，需对齐时也可不空或多空格，“sizeof”运算符建议也在其后空一
格，不论是否有括号，对语句行后加的注释应用适当空格与语句隔开并尽可能对齐。
（3）对齐：原则上关系密切的行应对齐，对齐包括类型、修饰、名称、参数等各部分对齐。
另每一行的长度不应超过屏幕太多，必要时适当换行，换行时尽可能在“,”处或运算符处，换行后
最好以运算符打头，并且以下各行均以该语句首行缩进，但该语句仍以首行的缩进为准，即如其下
一行为“{”应与首行对齐。
（4）空行：程序文件结构各部分之间空两行，若不必要也可只空一行，各函数实现之间一般
空两行，由于BCB会自动产生一行“//------”做分隔，另因每个函数还要有函数说明注释，故通常
只需空一行或不空，但对于没有函数说明的情况至少应再空一行。对自己写的函数，建议也加上
“//------”做分隔。函数内部数据与代码之间应空至少一行，代码中适当处应以空行空开，建议
在代码中出现变量声明时，在其前空一行。类中四个“p”之间至少空一行，在其中的数据与函数之
间也应空行。
（5）注释：对注释有以下三点要求：
A.必须是有意义；
B.必须正确的描述了程序；
C.必须是最新的。
注释必不可少，但也不应过多，以下是四种必要的注释：
A.标题、附加说明；
B.函数说明：对几乎每个函数都应有适当的说明，通常加在函数实现之前，在没有函数实现
部分的情况下则加在函数原型前，其内容主要是函数的功能、目的、算法等说明，参数说明、返回
值说明等，必要时还要有一些如特别的软硬件要求等说明；
C.在代码不明晰或不可移植处应有少量说明；
D.及少量的其它注释。
注释有块注释和行注释两种，分别是指：“/**/”和“//”建议对A用块注释，D用行注释，B、C则
视情况而定，但应统一，至少在一个单元中B类注释形式应统一。
4． 命名规范：坚持采用匈牙利变量命名惯例，类型名称按Borland惯例用“T”做前缀，参数的
命名统一以小写“a”前缀，所有标识符一律用英文或英文缩写，杜绝采用拼音，标识符中每个单词
首字母大写，缩写词汇一般全部大写，只在必要时加“_”间隔词汇，用 #define 定义的宏一般全
部大写，其它具体细节待定。

三、补充说明：本规范历史：

1996年 8月
1.0口头版
1997年11月20日
2.0版
1999年 7月 1日
3.0版
2000年12月16日
3.01修订版

 

附录一

对 Borland Delphi 的补充说明：
虽然 Delphi 是大小写无关的，但建议仍按大小写有关的方式编程，保持标识符的大小写一致，对
于关键字的大小写可采用全部小写，全部大写或首字母大写等方式，但必须保持统一。 Delphi 支
持多种多种块注释方式，建议采用“(* ... *)”的方式，以和编译指令“{$ ... }”及和 C/C++
有所区别。

附录二

匈牙利命名法(Hungarian-Notation)：
据说这种命名法是一位叫 Charles Simonyi 的匈牙利程序员发明的，后来他在微软呆了几年，于是
这种命名法就通过微软的各种产品和文档资料向世界传播开了。现在，大部分程序员不管自己使用
什么软件进行开发，或多或少都使用了这种命名法。这种命名法的出发点是把量名变按：属性+类型
+对象 描述的顺序组合起来，以使程序员作变量时对变量的类型和其它属性有直观的了解，下面
是HN变量命名规范，其中也有一些是我个人的偏向：

属性部分
全局变量
g_
常量
c_
c++类成员变量
m_
静态变量
s_

类型部分
指针
p
函数
fn
无效
v
句柄
h
长整型
l
布尔
b
浮点型（有时也指文件）
f
双字
dw
字符串
sz
短整型
n
双精度浮点
d
计数
c（通常用cnt）
字符
ch（通常用c）
整型
i（通常用n）
字节
by
字
w
实型
r
无符号
u

描述部分
最大
Max
最小
Min
初始化
Init
临时变量
T（或Temp）
源对象
Src
目的对象
Dest

 

这里顺便写几个例子：
hwnd ： h 是类型描述，表示句柄， wnd 是变量对象描述，表示窗口，所以 hwnd 表示窗口句柄；
pfnEatApple ： pfn 是类型描述，表示指向函数的指针， EatApple 是变量对象描述，所以它表示
指向 EatApple 函数的函数指针变量。
g_cch ： g_ 是属性描述，表示全局变量，c 和 ch 分别是计数类型和字符类型，一起表示变量类
型，这里忽略了对象描述，所以它表示一个对字符进行计数的全局变量。
上面就是HN命名法的一般规则。

 

附录三

其它的编程风格规范（供参考）：
在软件编程过程中，如果每个程序员都按自己的习惯和风格编写程序，这种因人而异的程序风格势
必降低程序的可读性，对软件的测试、交流、重用以及软件的维护产生极为不利的影响。为了解决
这个问题，最终提高开发效率，必须执行本规范。
本规范在编程基本风格、可读性、结构化、正确性与容错性、可重用性等方面提出了要求，它是程
序员编程素质的综合体现。
程序员的编程水平＝编程规范＋编程效率。

1.基本要求
1.1程序结构清析，简单易懂，单个函数的程序行数不得超过100行。
1.2打算干什么，要简单，直接了当，代码精简，避免垃圾程序。
1.3尽量使用标准库函数和公共函数。
1.4不要随意定义全局变量，尽量使用局部变量。
1.5使用括号以避免二义性。

2.可读性要求
2.1可读性第一，效率第二。
2.2保持注释与代码完全一致。
2.3每个源程序文件，都有文件头说明，说明规格见规范。
2.4每个函数，都有函数头说明，说明规格见规范。
2.5主要变量（结构、联合、类或对象）定义或引用时，注释能反映其含义。
2.7常量定义（DEFINE）有相应说明。
2.8处理过程的每个阶段都有相关注释说明。
2.9在典型算法前都有注释。
2.10利用缩进来显示程序的逻辑结构，缩进量一致并以 Tab 键为单位，定义Tab为 6个字节。
2.11循环、分支层次不要超过五层。
2.12注释可以与语句在同一行，也可以在上行。
2.13空行和空白字符也是一种特殊注释。
2.14一目了然的语句不加注释。
2.15注释的作用范围可以为：定义、引用、条件分支以及一段代码。
2.16注释行数（不包括程序头和函数头说明部分）应占总行数的 1/5 到 1/3 。

3.结构化要求
3.1禁止出现两条等价的支路。
3.2禁止GOTO语句。
3.3用 IF 语句来强调只执行两组语句中的一组。禁止 ELSE GOTO 和 ELSE RETURN。
3.4用 CASE 实现多路分支。
3.5避免从循环引出多个出口。
3.6函数只有一个出口。
3.7不使用条件赋值语句。
3.8避免不必要的分支。
3.9不要轻易用条件分支去替换逻辑表达式。

4.正确性与容错性要求
4.1程序首先是正确，其次是优美
4.2无法证明你的程序没有错误，因此在编写完一段程序后，应先回头检查。
4.3改一个错误时可能产生新的错误，因此在修改前首先考虑对其它程序的影响。
4.4所有变量在调用前必须被初始化。
4.5对所有的用户输入，必须进行合法性检查。
4.6不要比较浮点数的相等， 如： 10.0 * 0.1 == 1.0 ， 不可靠
4.7程序与环境或状态发生关系时，必须主动去处理发生的意外事件，如文件能否逻辑锁定、打印机
是否联机等。
4.8单元测试也是编程的一部分，提交联调测试的程序必须通过单元测试。

5.可重用性要求
5.1重复使用的完成相对独立功能的算法或代码应抽象为公共控件或类。
5.2公共控件或类应考虑OO思想，减少外界联系，考虑独立性或封装性。
5.3公共控件或类应建立使用模板。