名副其实
- 选个好名字要花时间,但省下来的时间比花掉的多。
- 一旦发现有更好的名称,就换掉旧的。
- 好的名称会告诉你:它为什么会存在,它做什么事,应该怎么用。
避免误导
- 应该避免留下掩藏代码本意的错误线索。应当避免使用与本意相悖的词。
- 不要在名称中写出容器类型名。可以用group或bunchOf或者加s。
- 提防使用不同之处较小的名称。
- 以同样的方式拼写出同样的概念才是信息。拼写不一致就是误导。
误导产生问题原因:程序员大多数时候根本不看详细注释;用IDE的快速搜索功能
的时候会因为命名差距较小出现一堆无用的结果。
做有意义的区分
- 不要使用相近含义的单词,例如:ProductData,ProductInfo,这里Info和Data就是意义含混的废话。
- 废话是冗余,例如:nameString,这里name难道会是一个浮点数不成。
使用读得出来的名称
如果名称读不出来,讨论的时候就像个傻鸟。
使用可搜索的名称
- 不要使用
单字母名称
或数字常量
。很难在一大篇文字中找出来。因此长名称胜于短名称,搜得到的名称胜于用自造编码代写就的名称。 - 单字母名称仅用于短方法的本地变量,名称长短应与其作用域大小相对应。若变量或常量可能在代码中多处使用,则应赋其以便于搜索的名称。
避免使用编码
- 编码已经太多,不要在代码逻辑中又增加一种编码“语言”。
- 带编码的语言不利于发音,容易打错。
匈牙利语标记法:现代编程语言具有更丰富的类型系统,编译器记得并强制使用类型。而且,人们趋向于使用更小的类、更短的方法,好让每个变量的定义都在视野范围之内。
成员前缀:应当把类和函数做的足够小,消除对成员前缀的需要。使用某种可以高亮或用颜色标出成员的编译环境。
接口与实现:我不想让用户知道我给他们的是接口。如果接口和实现必须选一个来编码,选实现,加Impl。
避免思维映射
不要让读者在脑海中把你的名称翻译为他们熟知的名称。这说明你起的名称不够明确
。
类名
名词或名词词组
方法名
- 动词或动词词组。
- 属性访问器、修改器和断言应该根据其值命名,并依JavaBean标准加上get、set和is前缀。
- 重载构造器时,使用:描述了参数的静态工厂方法名,将相应的构造器私有化,强制使用这种命名手段。
别扮可爱
你的幽默、文化背景,别人可能不懂。
每个概念对应一个词
给每个抽象概念选一个词,并且一以贯之。
别用双关语
避免将同一单词用于不同目的。
使用解决方案领域名称
只有程序员才会读你的代码。所以,尽管用程序员都懂的术语。依据问题所涉领域来命名会让协作者总是跑去问客户每个名称的含义。
使用源自所涉问题领域的名称
这是在上一条无法使用的时候,才去使用的办法,至少负责维护代码的程序员能去请教领域专家。
优秀的程序员和设计师,其工作之一就是分离解决方案领域和问题领域的概念。与所涉问题领域更为贴近的代码,应当采用源自问题领域的名称。
添加有意义的语境
如果前面的都不好使了,给名称添加前缀就是最后一招了。当然更好的方案是创建一个类把字段封装进去,这样就提供了语境了。
不要添加没用的语境
只要短名称足够清楚,就要比长名称好。别给名称添加不必要的语境。精确是命名的要点。不要搞到:输入G,按下自动完成键,结果会得到系统中全部类的列表,列表恨不得有一公里那么长。这样搞的IDE都没法帮助你!!!