记得几年前读了一点代码整洁之道,当时只是粗略的读，里面的内容都忘记了，这次重新读，为了保证不会再忘记里面的内容，特意做了一些笔记，方便查阅

总结

作为一个英文不好的码农，可能最挠头的一件事就是命名了。可是这有是我们每天不得不面对的一个问题，怎么才能取一个好的命名呢？通过读这本书，我认为需要满足以下几点。

  1. 足够清楚表达意思，让人一目了然，并且不能有歧义。
  2. 尽量短小，如果短名称表达不清楚意思，就加长。
  3. 不加无用的前缀，语境
  4. 名称之间要有明显的区分
  5. 是英文单词或者单词组合，而不是自创的词语，或者拼写错误的单词。

下面这几条是具体解释阐述上面的结论的。

名副其实

  1. 一旦发现有更好的名称，立刻替换
  2. 如果名称需要注释来补充，那么就不算是名副其实
  3. 选择体现本意的名称能让人更容易理解和修改代码

1和2 主要是为了要说明命名应该清楚表达其意思。

避免误导

  1. 别用accountList来指代一组账号，除非它真的是List类型
  2. 提防使用不同之处较小的名称。这样区分成本太高
  3. 避免使用小写字母l和大小字母O作为变量名，这样容易误导成数字1 和 0

2和3 主要是说名称之前要有明显的区分。

做有意义的区分

  1. 名称后面添加数字系列（a1,a2,a3…）是远远不够的，这样纯属误导，完全没有提供正确的信息
  2. 不能以拼写错误代替区分已经存在的名称。
  3. 废话是一种没意义的区分。例如一个项目中Product类，和ProductData,ProductInfo，虽然名称不同，但是意思无区别，Info和Data就像是a,an,the一样，是意义混淆的废话
  4. Variable一词永远不应该出现变量名中，Table一词永远不应当出现在表名中

使用读的出来的名称

  1. 别使用傻乎乎的自造词，而使用恰当的英语词汇，并且尽量别缩写，因为缩写后就可能变成其他意思了

使用可搜索的名称

  1. 单字母和数字常量有一个问题，就是很难在一大堆代码中找到，但是如果定义一个很长的名称表示，就比较容易搜索，这个应该也是面向对象的一种思想-封装吧。
  2. 长名称胜于短名称，搜得到的名称胜于自造的名称
  3. 单字母仅仅用于短方法的本地变量中，名称长短应该与作用域大小相对应，这样便于搜索

避免使用编码

  1. 使用匈牙利标记法
  2. 省略成员前缀，因为人们现在会直接无视前缀，只看名称中有意义的部分，代码读的越多，眼里越没有前缀，最终前缀成为了不入法眼的废料，既然是废料，直接省略
  3. 使用后缀Impl来表示实现类，而不是使用前缀I来表示该类是一个接口类

避免思维映射

  1. 不应当让读者在脑中把你写的名称翻译成他们熟知的名称。
  2. 单字母不是一个好选择，读者必须在脑海中将它映射为真实的概念
  3. 聪明的程序员和专业程序员之间的区别在于
    • 专业程序员了解，明确是王道。
    • 专业程序员善用其能，编写其他人能理解的代码

类名

  1. 使用名词或者名词短语
  2. 避免使用Manager，Processor,Data或者Info这样的类名。

方法名

  1. 动词或者动词短语

别扮可爱

  1. 宁可明确，勿为好玩
  2. 程序员都是很严谨的，可能get不到可爱的点
  3. 扮可爱常常体现在使用俗语或者俚语
  4. 言到意到，意到言到

每个概念对应一个词

给每一个抽象概念选一个词，并且一以贯之。如果在同一堆代码中有cotroller,又有manager，还有driver，会让人困惑的

别用双关语

  1. 代码作者应尽力写出易于理解的代码，让别人一目了然，而不必殚精竭虑的研究
  2. 应该使用大众化的方式的平装书，而不是学究研究半天才能明白的

使用解决方案领域名称

只有程序猿才会读你的代码，尽管用计算机科学术语，算法名，模式名，数学术语。

使用源自所涉问题领域的名称

  1. 有些的程序员和设计师，其工作之一就是分离解决方案领域和问题领域的概念

添加有意义的语境

但是还是建议通过良好命名的类，函数或者名称控件来给读者提供语境。如果办不到，那就只好通过给名称添加前缀，从而给读者提供语境。

不要添加无用语境

如果所有类前都添加某一个前缀，那相当于没添加，没添加的东西就直接省略掉。

最后

使用现代工具对付细节，好让自己集中精力把代码写的就像词语篇章，至少像是表和数据结构

编码规范

  1. 变量名称前面不添加m或者_,没用
  2. 使用后缀Impl来表示实现类

搬运地址：

代码整洁之道