命名
名副其实
- 选择一个好名字，省下来的时间要比花掉的多
- 如果名称需要注释来补充，那就不算是名副其实
theList这种类型的命名就感觉代码很模糊，不知道是表现得什么
避免误导
- hp、aix、sco、android、java这都不是好名字
- acountList指一组用户，除非真是list否则用，groupOfAcout要比grouplist好的多
做有意义的区分
- a1、a2这些是没有任何意义的
- variable永远不应该出现在变量名中，table永远不应该出现在表中
- nameString会比name好吗？这是否定的
- 如果缺少规定，moneyAcount与money就没有任何区别
使用读的出来的名字
- 自己制造的词，别人不理解，没有任何意义
- 见名知意，要让别人理解成为你所表达的意思
使用可搜索的名字
- 名称长短与作用域相对应
- 举例说明:例如
WORK_DAYS_PER_WEEK要比数字5好找的多
避免使用编码
- 编码已经太多了，不要再找麻烦了。
- 把类型或者作用域编进名称里面，徒然增加了解码的负担
成员前缀
- 不必用m_来表明成员变量，应当把类和函数做的足够小
- 前缀变得越来越像是废物
避免思维映射
- 不应当让读者在脑中把你的名称翻译成他们认为的名称
- 明确是王道
类名
应该是名词或者是名词短语，例如Customer,AddressParse
函数名字
应该是动词或者是动词短语，postPayment
别扮可爱(别装逼)
- 例如helloKitty之类，千万不要用，即便是自己的个性也不要用
每个概念对应一个词
- 给每个抽象的概念选一个词，并且一以贯之
- 例如一堆代码中，既有controller又有manager还有driver，就会让人感觉困惑，这几个词语意义差不多，选择一个即可
不用双关
- 一语双关在代码中是不可取的
- add方法列表，已经有了连接两个值的方法，把单个值放入Collection中，最好使用append或者insert之类的
使用解决方案领域名称
- 只有程序员才会读你的代码，所以尽管使用那些算数名、数学术语吧
使用源自所涉及领域的名称
- 优秀的程序员和设计师，其工作之一就是分离解决方案领域和问题领域的概念
添加有意义的语境
- 假如在某个方法中看到state变量，什么感觉？草泥马
- 添加addrState是一个好的方案
- 不要添加没用的语境
最后的话
- 取名字最难的地方在于需要良好的描述技巧和共有的文化背景，这是一种教学的问题
- 名称取得好或者改的好事半功倍