通用命名规则

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

unix like 风格：单词用小写字母，每个单词直接用下划线„_‟分割，例如：text_mutex， kernel_text_address。

Windows 风格：大小写字母混用，单词连在一起，每个单词首字母大写。不过 Windows 风格如果遇到大写专有用语时会有些别扭，例如命名一个读取 RFC 文本的函数，命令为 ReadRFCText，看起来就没有 unix like 的 read_rfc_text 清晰了。

原则 3.1 标识符的命名要清晰、明了，有明确含义，同时使用完整的单词或大家基本可以理解的缩写，避免使人产生误解。

尽可能给出描述性名称，不要节约空间，让别人很快理解你的代码更重要。

示例：好的命名：

int error_number;
int number_of_completed_connection;
不好的命名：使用模糊的缩写或随意的字符：
int n;
int nerr;
int n_comp_conns;

原则 3.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.1 产品/项目组内部应保持统一的命名风格。

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

建议 3.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

建议 3.2 尽量避免名字中出现数字编号，除非逻辑上的确需要编号。

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

#define EXAMPLE_0_TEST_
#define EXAMPLE_1_TEST_
应改为有意义的单词命名
#define EXAMPLE_UNIT_TEST_
#define EXAMPLE_ASSERT_TEST_

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

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

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

建议 3.4 平台/驱动等适配代码的标识符命名风格保持和平台/驱动一致。

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

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

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