最近学习了《代码整洁之道》，感触很深，于是把其中的要点整理出来给大家。
1.名副其实
☛要点
如果名称需要注释来补充，那就不算是名副其实
☹糟糕代码
-
theList 中是什么类型的东西？
-
theList 0下标的意义是什么？
-
值4的含义是什么？
-
我们怎么使用返回的列表？
☺改进代码
-
假设这是一段扫雷游戏代码。
-
盘面就是theList的单元格列表，将其命名为gameBord
-
0下标是一种状态值
-
状态值‘4’表示已标记
☺更进一步
不用int[]表示单元格，而是用一个单独的类，该类包括一个名副其实的函数（isFlagged）
2.避免误导
3.做有意义的区分
☛要点
以数字系列命名（a1,a2…）是依义命名的对立面。这样的名称纯属误导——完全没有提供正确信息
如果有一个Product类，还有一个ProductInfo或者ProductData，他们虽然名称不同，毫无任何区别
variable(可变的)一词永远不应出现在变量名中
Table一词永远不应出现在表名中
nameString会比name好吗？难道name会是一个浮点数？
☹糟糕代码
如果参数名为source和destination（目的地,目标,终点）这个函数就会像样许多
getActiveAccount();
getActiveAccounts();
getActiveAccountInfo();
以上区分毫无意义
4.使用能读出来的名称
☛要点
人类进化到大脑中专门有一部分来处理语言，若不善加利用，实在是种耻辱
☹糟糕代码
private Date genymdhms;//生成日期，年，月，日，时，分，秒1
☺改进代码
private Date generationTimeStamp;//生成时间戳
5.使用可搜索名称
☛要点
单字母名称和数字常量很难在一大篇文字中找出来
若变量或常量可能在代码中多次使用，应赋其便于搜索的名称
☹糟糕代码
☺改进代码
6.避免使用编码
☛要点
不必用m_前缀来标注成员变量。应把类和函数做的足够小，消除成员前缀的需要
这段看的有点懵逼。。。
☹糟糕代码
private String m_des;
☺改进代码
private String description;
7.避免思维映射
☛要点
仅仅是因为有了a和b，就要取名为c，实在非像样的理由。
专业程序员了解，明确是王道
8.类名
☛要点
类和对象应该是名称或名词短语，如Customer，Account，避免使用Manager，Processor，data或Info这样的类名。
类名不应当是动词。
9.方法名
☛要点
方法名应当是动词或动词短语，如PostPayMent，deletePage或save。
重载构造器时，使用描述了参数的静态工厂方法名。例如
Complex fulcrumPoint = Complex.FromRealNumber(23.0);1
同常好于
Complex fulcrumPoint = new Complex(23.0);1
可以考虑将对应的构造器设置为private，强制使用这种命名手段。
10.别扮可爱
☛要点
谁会知道HolyHandGrenade(圣手*雷手**)这个函数是用来做什么的呢？DelteItems或许是更好的名称
言到意到，意到言到。
11.每个概念对应一个词
☛要点
给抽象概念对应一个词，并且一以贯之。
在同一堆代码中。有manager又有controller，driver，就会令人困惑。
总之，不要用多个词表示一个意思！
12.别用双关语
☛要点
避免用同一单词表示不同目的。
比如在多个类中都有add方法，该方法通过增加或链接两个现有值来获得新值。假设新类中有个方法，把单个变量放在集合中，这个方法如果再叫add，就是双关了，应该用insert或append好一些。
总之，不要用一个词表示多个意思！
13.使用解决方案领域的名称
☛要点
只有程序员会读你的代码，尽管使用程序员看得懂的名称。使用问题所涉领域来命名，可不算是聪明的做法。
14.使用源自所涉问题领域的问题
☛要点
如果不能使用程序员熟悉的术语来命名，使用问题所涉领域来命名。
15.添加有意义的语境
☹糟糕代码
☺改进代码
上列函数有点过长，要分解这个函数，需要创建一个GuessStatisticsMessage的类，把三个变量作为该类的成员字段。
16.不要添加没用的语境
☛要点
假设有一个“加油站豪华版”（Gas Station Deluxe）的应用，在其中给每个类添加GSD前缀就不是什么好点子了。
17.最后的话
不妨试试上面这些规则，看你的代码可读性是否有所提升。如果你是在维护别人写的代码，使用重构工具来解决问题。效果立竿见影，而且会持续下去。
以上出自：《代码整洁之道》第一章：有意义的命名
整理：呆萌小土豆