原文地址:关于代码命名规范性——命名法(命名规则)的闲谈
作者:葱烧烙饼
今天空余时间挺多的,谈谈代码的命名规则。
项目开发当中,每个程序员的命名法都独树一帜,看到命名法就像看到其人一般。有的人长得好看,有的人长得难看,有的人高,有的人矮,还有的人……他不是人。
好的命名让人看清来容易理解,容易辨识。差的命名,越看越迷糊。你们不会知道有人用aa,aaa也打出一片天地,你们或许也不会知道为什么bike会被某人用作“判断是否在线支付”标识。他们思想跳跃及理解能力超乎凡人的想象。多年许久,你忘记某个知识点并去查阅它的时候,发现某段示例代码中,有bike这个你永远不能忘记的极其罕见的被举例的命名,你额光一闪,多年的困惑终于被揭开了。啊,神啊,我终于懂了。噢,你也懂了。
不开玩笑了,其实没有那么严重。
有时候为了赶进度,我们不可能一个个命名去审核,去追究。当项目需要开发的新功能与之前的功能相冲突的时候,此时你就要崩溃了。这变量是谁命名的?这操蛋的东西是谁写的?hdfk是什么鸟东西!当然,要追究起源头来肯定是比较容易的,找一下哪个模块是哪些人负责开发的,然后再对比一下命名风格,问一句谁写的自然有人承认,攻城师一般都是比较诚实的嘛,哈。
这里就涉及到快速开发结构思考不完全(产品设计规划变动等原因也很大)带来的重构代价,修改这玩意哥还不如重写一个!我相信此时你会想,而且很大可能你会这样做的。因为这样做确实是比较快,而且很多时候你会冠冕以代码运行效率更高的理由去说服自己去重构……
其实目前知名度较高的主流命名法有三种,一种是匈牙利命名法,一种是驼峰命名法,还有一种是下划线法。
噢,不对,还有一种非主流命名法——“我流”。所谓我欲乘风归去,你拦也拦不了。
匈牙利命名法拥有蛋痛那多的争议,以至于三隔五天便有人来追杀围堵,惟恐它继续繁衍祸害后代攻城师。一句话总结匈牙利命名法就是:复杂麻烦难以认记。刚初入编程的菜鸟,谁不见MFC、WIN API、DX代码的命名而一头雾水斟酌十数遍?
驼峰命名法和下划线法其实规则性都不是很强,只不过是规定了它体形是什么样而已,样貌是帅是挫,它压根不管。当驼峰命名法的驼峰多起来就看不清是啥的。下划线法跟驼峰命名法差不多,至少看起来清晰点。写多几个下划线,你也难受,那单词长度可是哗哗哗的。
说了那么多,我也没说那种命名法要好,其实最重要还是自己用得舒心,别人看得畅心。你好,我好,大家好,才是真的好。
实际开发之中最好还是要协调团队的编码习惯,能配合团队的编码习惯尽量配合。即便你觉得那个东西很糟糕(如果特别糟糕的话,我认为你有义务去提醒团队所有人开发者改掉这些习惯)。若你采用团队编码习惯,即便这个代码幻化出来的人很丑,至少它很聪明很善良。倘若你遵循自己觉得闪亮帅气的规则来写,那么此代码幻化出来的,没人保证它还是个人,或许只是个牲口。
所以,协调团队编码习惯很重要,觉得不好的话,请指出,团队一起改正而不单人是特立独行。
现在的编辑器比起十数年前的要强大多了,鼠标一指各种类型引用都出来了,压根不需要猜这个是什么个玩意。不过许多人也会跳大神说,匈牙利理解类型更快捷。不同语言的不同特性其实也对命名法有了新的挑战,具体我也不多说,这些语言的特性也同时决定其命名有更好的独特性,所以不同的编码风格适用于不同的团队不同的语言也是有道理的。
命名这玩意跟JS后面是否加“;”这玩意一样蛋痛,别跟我吵这个,我不理你的。
下面是个人在命名规则上的癖好(哈哈,对,我会强迫周围人也用……):
1.一般来说采取【小写类型名前缀 + 下划线 + 含义】的做法。(含义一般用驼峰,尽量用英文表达完词义,控制在30字符以内,太长会让人崩溃。)
example:ch_ClassName,arr_StudentInfo,b_Found,f_TotalMoney,lpsz_MarkPlace
2.对于小函数(30行以内)或临时代码变量,里面的变量可以不加类型前缀。不过最好加TEMP前缀,以辨识为临时变量,只用于附近这一块。【temp + 下划线 + 含义】
temp_Sql,temp_ClassInfo,temp_Pointer,sql,classInfo,pointer
3.i,j,k,flag等大部分人一看知道啥意思的直接用。
4.全局变量一定要标明。
5.尽量将风格贴合原项目代码的变量命名。
6.所有缩进全部使用空格。少用TAB,假设偶尔游泳TAB的话,将TAB设成2个空格长度。
7.SQL语句中,关键字全部大写,表名、对象全部小写。如下:
SELECT user_name,user_id FROM table_users AS u
LEFT JOIN table_room AS r ON r.user_id = u.user_id
WHERE user_id <> '10'