概述
目前比较使用的如下几种命名风格:
unix like
风格:单词用小写字母,每个单词直接用下划线
‘_’
分割,例如
text_mutex
,
Windows
风格:大小写字母混用,单词连在一起,每个单词首字母大写。不过
Windows
风格如果遇到大写专有用语时会有些别扭,例如命名一个读取
RFC
文本的函数,命令为
ReadRFCText
,看起来就没有
unix like
的
read_rfc_text
清晰了。
匈牙利命名法是计算机程序设计中的一种命名规则,用这种方法命名的变量显示了其数据类型。匈牙利命名主要包括三个部分:基本类型、一个或更多的前缀、一个限定词。
注意,不要使用匈牙利命名法
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
风格均有其拥趸,产品应根据自己的部署平台,选择其中一种,并在产品内部保持一致。
例外:即使产品之前使用匈牙利命名法,新代码也不应当使用。
4
、用正确的反义词组命名具有互斥意义的变量或相反动作的函数等
示例:
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
5
、尽量避免名字中出现数字编号,除非逻辑上的确需要编号
示例:如下命名,使人产生疑惑。
#define EXAMPLE_0_TEST_
#define EXAMPLE_1_TEST_
应改为有意义的单词命名
#define EXAMPLE_UNIT_TEST_
#define EXAMPLE_ASSERT_TEST_
6
、标识符前不应添加模块、项目、产品、部门的名称作为前缀
说明:很多已有代码中已经习惯在文件名中增加模块名,这种写法类似匈牙利命名法,导致文件名不可读,并且带来带来如下问题:
1
第一眼看到的是模块名,而不是真正的文件功能,阻碍阅读;
2
文件名太长;
3
文件名和模块绑定,不利于维护和移植。若
foo.c
进行重构后,从
a
模块挪到
b
模块,若
foo.c
中有模块名,则需要将文件名从
a_module_foo.c
改为
b_module_foo.c
7
、命名规范
7.1
文件命名统一采用小写字符
说明:因为不同系统对文件名大小写处理会不同(如
MS
的
DOS
、
Windows
系统不区分大小写,但是
Linux
系统则区分),所以代码文件命名建议统一采用全小写字母命名。
7.2
全局变量应增加
“g_”
前缀
7.3
静态变量应增加
“s_”
前缀
说明:增加
g_
前缀或者
s_
前缀,原因如下:
首先,全局变量十分危险,通过前缀使得全局变量更加醒目,促使开发人员对这些变量的使用更加小心。
其次,从根本上说,应当尽量不使用全局变量,增加
g_
和
s_
前缀,会使得全局变量的名字显得很丑陋,从而促使开发人员尽量少使用全局变量。
7.4
禁止使用单字节命名变量,但允许定义
i
、
j
、
k
作为局部循环变量
7.5
不建议使用匈牙利命名法。
7.6
函数命名应以函数要执行的动作命名,一般采用动词或者动词+名词的结构。
7.7
对于数值或者字符串等等常量的定义,建议采用全大写字母,单词之间加下划线
‘_’
的方式命名(枚举同样建议使用此方式定义)。
示例:
#define PI_ROUNDED 3.14
7.8
除了头文件或编译开关等特殊标识定义,宏定义不能使用下划线
‘_’
开头和结尾。
说明:一般来说,
’_’
开
头
、
结
尾的宏都是一些内部的定
义
,
ISO/IEC 9899
(俗称
C99
)中有如下的描述(
6.10.8 Predefined macro names
):
最后
以上就是着急白昼为你收集整理的c语言标识符命名作用,C语言-标识符命名的全部内容,希望文章能够帮你解决c语言标识符命名作用,C语言-标识符命名所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复