首页
Web开发
Windows程序
编程语言
数据库
移动开发
系统相关
微信
其他好文
会员
首页
>
其他好文
> 详细
代码命名规范
时间:
2015-01-10 21:03:37
阅读:
227
评论:
0
收藏:
0
[点我收藏+]
标签:
该篇日志是一篇阅读材料的总结。文件下载地址:
https://class.stanford.edu/c4x/Engineering/CS-144/asset/Naming.pdf
(也可从百度云盘下载:
http://pan.baidu.com/s/1hqf6KIw
)。总结如下:
名称应该反映代码作者的目的。
这节省了不必要的注释(如 int t; // Time since born in days 可以改为 int daysSinceBorn;),并使代码变得易于读懂。
易读和易于互相讨论,这将是以下全部命名规范的关注点
。关于注释的另一个需要注意的问题:时间紧张时,没有多少人会读注释,而是由名称猜含义。
避免出现魔术数字,用宏定义取代数字;避免’莫名其妙的操作’,各种判断或循环控制语句读起来应该尽量像正常的句子。
避免歧义。
计算机科学中有一些字母组合,因为广为人知所有具有了约定俗成的含义,如hp,aix,list等。所以一个“nameList”的变量,会马上给人以“这是一个链表”的印象;如果它事实上不是一个链表,那么“AccountGroup”就是更好的名字。
另一种导致歧义的原因是两个名字长得太像。比如“ThisIsOneName”与“ThisIsOnName”区别小且不宜一眼看出。另外,小写L(l)和1在有些编辑器里很像,0和O也是如此;应留心这一问题。
不同名称的含义应该有明显的区别。如“StellarInfo”和“StellarData”在含义上没有什么区别,如果用来代表两个不同的东西,则很容易让使用者(自己或他人)用错。这可以认为是上面讲的‘歧义’的一个变种(不是跟约定的名称冲突,而是在语义上和自己的其他名称冲突)。
与上面相关的,一个概念应该使用同一个单词。比如有两个类,Dog和Cat,那么用’feet’和’paws’来分别表示“狗的爪”和“猫的爪”就不是好习惯,因为这样你就不得不记清楚究竟狗和猫哪一个对应feet。但是--
如果一个单词对不同对象有不同的含义,不能为了’一致性’而使用,而是应该对特定的类型选择最为合适的名字。比如两个数字相加,用’add’;向一个列表中加入元素,似乎也可以用’add’,但意义却与上面的二者’相加’明显不同。故应考虑’append’。
使用能够拼读的名字。比如“tpshms”就没办法拼读,这样在跟其他程序员讨论时,就只能“tee-pee-es-aich-em-es”这样一个字母一个字母来说,费时费力;相反的,“userId”就同意多了。
名字应易于搜索。这具有很明显的实际意义:快速定位到感兴趣的变量的定义处,对高效地理解一段代码至关重要。不易搜索的变量名包括单独的数字和字母个数少的字符串等。比如,5这个数字就很难grep到目标位置,但定义一个宏:MIN_ELEMENT_NUMBER就很容易搜索到。原则上名字的长度应大致和其所在的域的代码长度成正比;但无论如何,尽量用描述性强的名字。
不要使用表示类型的前缀。匈牙利命名法在数据类型较少的时代是有用的,但现代编程语言,类型多种多样,且可以互相嵌套,用匈牙利命名法或类似的命名法,只会导致很多不容易发音,且本质上没人关心的前缀。一句话:命名时只关注该变量的含义,不要管它的类型。
避免无意义的命名。如循环指标使用i,j,k就是坏习惯。它们没有任何意义。
不要耍小聪明。比如使用特有的典故(#define hu_lu_wa 7);但阅读代码的人可能来自不同的文化,完全不懂这里面的幽默,因此只会导致困惑。实在忍不住要写,就把幽默放到注释里去,不忙的人或许会读一读。
使用合适的动词-名词结构。比如一个类的method,可以命名为getName(这种首个单词小写,后面单词首字母大写的方式,称为camel casing);名称更改操作可以是’fred’.changeNameTo(“mike”),注意到里面甚至用了介词to--目的只有一个:让一个函数语句像是一个正常的句子。
明确两类命名方式。一类命名反应技术细节,一类命名描述特定对象。基本精神是,位于软件结构的最外层函数应该更反映对象本身的性质,比如car.weight()或star.age();而底层实现应该与解决方案相关—这是很自然地,因为通常底层实现是不依赖于具体对象的,比如常用的库里的函数。
对可能造成歧义的变量名添加上下文。比如一个变量名为tree,就很难确定它是数据结构里的各种树,还是森林里的一棵树。解决方案是把它放到一个类/名字空间/函数里面;或者加前缀也是个办法,比如oak_tree。
不要添加无谓的前缀。比如你要给学校写个网关软件,里面的地址命名为sjtuAddress就不是好习惯;因为所有的变量都具有sjtu这一属性,所以干脆都不要写。
与上面相关的一点:越具有描述性越好,并不意味着名字里的字母越多越好;事实上,在同样清晰地情况下,字母越少越好。
如果你发现以前代码的名字不合理,不要因为担心’其他程序员可能会抱怨’而不去采取行动。事实上,一般来说他们会感谢你把名字修改地更加合理。
代码命名规范
标签:
原文地址:http://www.cnblogs.com/infty/p/4215550.html
踩
(
0
)
赞
(
0
)
举报
评论
一句话评论(
0
)
登录后才能评论!
分享档案
更多>
2021年07月29日 (22)
2021年07月28日 (40)
2021年07月27日 (32)
2021年07月26日 (79)
2021年07月23日 (29)
2021年07月22日 (30)
2021年07月21日 (42)
2021年07月20日 (16)
2021年07月19日 (90)
2021年07月16日 (35)
周排行
更多
分布式事务
2021-07-29
OpenStack云平台命令行登录账户
2021-07-29
getLastRowNum()与getLastCellNum()/getPhysicalNumberOfRows()与getPhysicalNumberOfCells()
2021-07-29
【K8s概念】CSI 卷克隆
2021-07-29
vue3.0使用ant-design-vue进行按需加载原来这么简单
2021-07-29
stack栈
2021-07-29
抽奖动画 - 大转盘抽奖
2021-07-29
PPT写作技巧
2021-07-29
003-核心技术-IO模型-NIO-基于NIO群聊示例
2021-07-29
Bootstrap组件2
2021-07-29
友情链接
兰亭集智
国之画
百度统计
站长统计
阿里云
chrome插件
新版天听网
关于我们
-
联系我们
-
留言反馈
© 2014
mamicode.com
版权所有 联系我们:gaon5@hotmail.com
迷上了代码!