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

总结

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

  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来表示实现类

搬运地址:

代码整洁之道