代码整洁之道-<有意义的命名>
代码整洁之道 一书相关读书笔记，整洁的代码是自解释的，阅读代码应该如同阅读一篇优秀的文章，见字知意，能够一下子明白大概的代码功能。代码首先要能读懂，其次才去要求功能实现。
作为开发者来说，在现在基本都讲究团队合作的工作方式下，规范远比功能重要，开发的功能也许在版本迭代中就不复存在了，但是规范却是一直存在的。
为了整洁的代码，就必须遵循一些统一的团队规范。混乱不堪连命名都无法取好的代码，只会给增加后续接手人员维护的成本
1.名副其实
名副其实说起来简单，但是这是个很严肃的事情，选好好名字要花时间，但是省下的时间比花掉的多，注意命名，而且一旦发现更好的名称，就换掉旧的
变量、函数或者类名应该已经答复了所有的大问题，当你看的这个名字的就应该知道他是干什么
int d;//消失的时间，以日计
这里名称d什么也没有说明，他没有引起对时间消失的感觉，更别说以日计，有人会说后面不是有注释的，但是你使用的时候你看到d能知道什么意思吗？还要去翻过去看注释.我们做的是读懂代码。而不是读懂注释，当然这并不是说注释没有意义，只是如果代码能读懂何必用注释
int elapsedTimeInDays;//消失的时间，以日计
这样这个变量就真真的名副其实了。
我们宁愿命名很长也要名副其实
2.避免误导
int[] acountntList；
这里我们给一个数组命名为acountList，这明显是个误导的命名，给一个数组命名成了list那我们操作这个数组的第一个想到的是不是使用list的方法呢？
3.做有意义的区分
以数字系列命名a1,a2.....aN是依义命名的对立面，这样命名完全没有提供正确信息
试看
public static void copyChars(char a1[],char a2[]){
for(int i=0;i如果参数名改为source和destination,这个函数就会像样许多
废话是另一种没意义的区分。假设你有一个Product类，如果还有一个ProductInfo或ProductData类，他们虽然名称不同，意思却无区别
下面是一个获取账户信息的函数
getAccount();
getAccounts();
getAccountInfo()
程序员要获取账户，他知道该调哪个函数吗？
4.使用读的出来的名称
尽量使用常用的易识别的单词吗命名
5. 成员前缀
也不必用m前缀来标明成员变量，应当把类和函数做的足够小，消除对成员前缀的需要
6.接口的命名
前导词I被滥用，比如使用I开头，比如IShapFactory
通常一个接口应该命名成这样
一个形容词，比如Runnable（可以运行的）
一个名词，比如List（列表）
一个复合名词，比如OnClickListener（被点击的监听者）
代码示例
interface OnReasonItemSelectedListener {
fun onReasonItemSelected(itemId: Int)
}
7.类名
类名和对象名应该时名词或者名词短语，如Customer,Account,避免使用Data或info这样的名词
注意：类名不应当是动词
8.方法名
方法名应该时动词或者动词短语，如postPayment、deletPage或save。属性访问器修改器和断言应该根据其值去命名
9.每个感念对应一个词
在同一堆代码中有controller ,又有manager就会令人困惑。为什么不全用controllers或者managers
对于那些会用到你代码的程序员，一以贯之的命名兼职就是天降福音
10.别用双关语
避免将同一单词用于不同目的，同一术语用于不同概念，基本上就是双关语了，如果遵循一词一义规则，可能在好多个类里面都会有add方法，只要这些add方法的参数列表和返回值在语意上等价，就一切顺利
但是，可能会有人决定“保持一致”而使用add这个词来命名，即便并非真的想要表示这种意思，比如，在多个类中都有add方法，该方法通过或连接两个现存值来获取新值
假设要写个新类，该类中有一个方法，把单个参数放到collection中，该把这个方法叫做add吗？虽然这样做貌似和其他add方法保持了一致，但实际语意不同，应该用insert或append之类的词来命名，把该方法命名为add就是双关语了