一、通用命名规则：

标识符的命名规则历来是一个敏感话题，典型的命名风格如unix风格、 windows风格等等，从来无法达成共识。实际上，各种风格都有其优势也有其劣势，而且往往和个人的审美观有关。我们对标识符定义主要是为了让团队的代码看起来尽可能统一，有利于代码的后续阅读和修改，产品可以根据自己的实际需要指定命名风格，规范中不再做统一的规定。

目前比较使用的如下几种命名风格：

  • unix like风格：
    单词用小写字母，每个单词直接用下划线 _ 分割。
    例如：text_mutex，kernel_text_address。
  • Windows风格：
    大小写字母混用，单词连在一起，每个单词首字母大写。
    不过Windows风格如果遇到大写专有用语时会有些别扭，例如：命名一个读取RFC文本的函数，命令为ReadRFCText，看起来就没有unixlike的read_rfc_text清晰了。
  • 匈牙利命名法
    匈牙利命名法是计算机程序设计中的一种命名规则，用这种方法命名的变量显示了其数据类型。
    匈牙利命名法主要包括三个部分：基本类型、一个或更多的前缀、一个限定词。
    匈牙利命名法最初在20世纪80年代的微软公司广泛使用，并在win32API和MFC库中广泛的使用，但匈牙利命名法存在较多的争议， 例如： .NET Framework，微软新的软件开发平台，除了接口类型一般不适用匈牙利命名法。 .NET Framework指导方针建议程序员不要用匈牙利命名法，但是没有指明不要用系统匈牙利命名法还是匈牙利应用命名法，或者是两者都不要用。与此对比，Java的标准库中连接口类型也不加前缀。

[规则]：

1、标识符的命名要清晰、明了，有明确含义

使用完整的单词或大家基本可以理解的缩写，避免使人产生误解。尽可能给出描述性名称，不要节约空间，让别人很快理解你的代码更重要。

正确示例：

int error_number;
int number_of_completed_connection;

错误示例：

int n;
int nerr;
int n_comp_conns;

2、除了常见的通用缩写以外，不使用单词缩写，不得使用汉语拼音

较短的单词可通过去掉“元音”形成缩写，较长的单词可取单词的头几个字母形成缩写，一些单词有大家公认的缩写，常用单词的缩写必须统一。协议中的单词的缩写与协议保持一致。对于某个系统使用的专用缩写应该在注视或者某处做统一说明。

正确示例：一些常见可以缩写的例子：

argument 可缩写为 arg
buffer 可缩写为 buff
clock 可缩写为 clk
command 可缩写为 cmd
compare 可缩写为 cmp
configuration 可缩写为 cfg
device 可缩写为 dev
error 可缩写为 err
hexadecimal 可缩写为 hex
increment 可缩写为 inc
initialize 可缩写为 init
maximum 可缩写为 max
message 可缩写为 msg
minimum 可缩写为 min
parameter 可缩写为 para
previous 可缩写为 prev
register 可缩写为 reg
semaphore 可缩写为 sem
statistic 可缩写为 stat
synchronize 可缩写为 sync
temp 可缩写为 tmp

3、产品/项目组内部应保持统一的命名风格

Unix like和windows like风格均有其拥趸，产品应根据自己的部署平台，选择其中一种，并在产品内部保持一致。

[建议]：

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

正确示例：

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 copy/paste up/down

2、尽量避免名字中出现数字编号，除非逻辑上的确需要编号

错误示例：如下命名，使人产生疑惑。

#define EXAMPLE_0_TEST_
#define EXAMPLE_1_TEST_

正确示例：应改为有意义的单词命名。

#define EXAMPLE_UNIT_TEST_
#define EXAMPLE_ASSERT_TEST_

3、标识符前不应添加模块、项目、产品、部门的名称作为前缀

很多已有代码中已经习惯在文件名中增加模块名，这种写法类似匈牙利命名法，导致文件名不可读，并且带来带来如下问题：

第一眼看到的是模块名，而不是真正的文件功能，阻碍阅读；
文件名太长；
文件名和模块绑定，不利于维护和移植。若foo.c进行重构后，从a模块挪到b模块，若foo.c
中有模块名，则需要将文件名从a_module_foo.c改为b_module_foo.c。

4、平台/ / 驱动等适配代码的标识符命名风格保持和平台

涉及到外购芯片以及配套的驱动，这部分的代码变动（包括为产品做适配的新增代码），应该保持原有的风格。

5、重构/修改部分代码时，应保持和原有代码的命名风格一致

根据源代码现有的风格继续编写代码，有利于保持总体一致。

二、文件命名规则：

[建议]：

文件命名统一采用小写字符

因为不同系统对文件名大小写处理会不同（如MS的DOS、Windows系统不区分大小写，但是Linux系统则区分），所以代码文件命名建议统一采用全小写字母命名。

三、变量命名规则：

[规则]：

1、全局变量应增加“g_” 前缀，静态变量应增加“s_”

首先，全局变量十分危险，通过前缀使得全局变量更加醒目，促使开发人员对这些变量的使用更加小心。

其次，从根本上说，应当尽量不使用全局变量，增加g_和s_前缀，会使得全局变量的名字显得很丑陋，从而促使开发人员尽量少使用全局变量。

2、禁止使用单字节命名变量，但 允许 定义i 、j、k作为局部循环变量

3、 不建议使用匈牙利命名法

匈牙利命名法是一种编程时的命名规范。基本原则是：变量名=属性+类型+对象描述。匈牙利命名法源于微软，然而却被很多人以讹传讹的使用。而现在即使是微软也不再推荐使用匈牙利命名法。历来对匈牙利命名法的一大诟病，就是导致了变量名难以阅读，这和本规范的指导思想也有冲突，所以本规范特意强调，变量命名不应采用匈牙利命名法，而应该想法使变量名为一个有意义的词或词组，方便代码的阅读。

变量命名需要说明的是变量的含义，而不是变量的类型。在变量命名前增加类型说明，反而降低了变量的可读性；更麻烦的问题是，如果修改了变量的类型定义，那么所有使用该变量的地方都需要修改。

4、使用名词或者形容词＋名词方式命名变量

四、函数命名规则：

[建议]：

1、函数命名应以函数要执行的动作命名，一般采用动词或动词＋名词的结构

正确示例：

//找到当前进程的当前目录
DWORD GetCurrentDirectory( DWORD BufferLength, LPTSTR Buffer );

2、函数指针除了前缀，其他按函数的命名规则命名

五、宏的命名规则：

[规则]：

1、对于数值或者字符串等等常量的定义，建议采用全大写字母，单词之间加下划线“_”的方式命名

枚举同样建议使用此方式定义;

正确示例：

#define PI_ROUNDED 3.14

2、除了头文件或编译开关等特殊标识定义，宏定义不能使用下划线“_”开头和结尾

一般来说，_ 开头、结尾的宏都是一些内部的定义，ISO/IEC 9899（俗称C99）中有如下的描述（6.10.8 Predefined macro names）:
None of these macro names (注：这里上面是一些内部定义的宏的描述)，nor the identifier defined,shall be the subject of a #define or a #undef preprocessing directive.Any other predefined macro names shall begin with a leading underscore fol lowedby an uppercase letter ora second underscore.