代码重构-有意义的命名

写在文前:大部分程序员都能写出计算机可以理解的代码，唯有优秀的程序员才能写出让人容易理解的代码

编码过程中，我们需要给变量，函数，参数，类，资源文件定义命名，合适的名字能给编码带来不少好处，比如易查找，见其名知其意等

以下就讲述一些合理命名的简单规则

名副其实

在查看变量，函数或者类起到什么作用的时候，根据它们的名字就应该知道个大概，包括为什么会存在，存在的作用，什么时候会被使用到。

举个Android下最简单的例子，比如 AddressAdapter这个类，从名字中你就能得知这个是一个关于地址的适配器，会在展示地址列表的时候被调用。

既然说到名副其实，还可以提一提魔术数.因为魔术数是典型的名不符实。
何为魔术数?

魔术数 ：是程式设计中所谓的直接写在程式码里的具体数值（如“10”“123”等以数字直接写出的值）。虽然程式作者写的时候自己能了解数值的意义，但对其他程式员而言，甚至制作者本人经过一段时间后，会难以了解这个数值的用途，只能苦笑讽刺“这个数值的意义虽然不懂，不过至少程式会动，真是个魔术般的数字”而得名。

比如:

for(int i=0;i<10;i++){
    if(i==4){
        //todo 
    }
}

上述for循环中，i==4中的这个 4就是魔术数，从这段代码来看，我们只知道i==4的时候，会有特殊的事情触发，但我们不知道4这个数字有什么意义。

for(int i=0;i<10;i++){
    if(isLogin(i)){
        //todo 
    }
}

Bolean isLogin(int i){
    return i==4;
}

如果改成这样的代码，我们便能轻易的知道当 i==4的时候表示已经登录，这样的话对if语句中所要执行的逻辑也能知晓个大概。

避免误导

你取得名字应该有特定的意义，同时还要注意不要与代语音中那些理所当然的术语所冲突。

举个简单的列子，比如有一个书的数据集(books),而有的人习惯命名为bookLists,当然这个名字也很合理，只不过这时一定要注意，承载这个数据集的容器究竟是什么。 如果容器是一个Map，那么bookLists这个名字就会误导别人，这时取名 bookMap 或者干脆就取 books 会更好.

同样的情况还会出现在其他时候，总的来说，不要让除你之外的其他人在看到某个名字的时候，会想到很多种解释。

做有意义的区分

当业务逻辑越来越复杂的时候，你就不得不往上堆砌更多的代码和变量。这时你可能就需要较劲脑汁的想变量名，尤其是那种含义类似，但又必须又多个变量的情况。

就比如数据集 mDatas 这个名字虽然意义不够明显，但是在只有一个数据集的情况下却也是十分容易理解。如果这时又必须一个变量来表示一个新的数据集，可能为了方便顺手就是 CTRL+D 复制加个2，一个mDatas2就出来了。

当然就算 mDatas mDatas2对我等程序员也就吹灰之力，况且数据集一般也不对多到mDatas3 4 5 这个样子。

只不过这种命名方式放到view中可能就不太一样的，业务逻辑一复杂，出个个10个8个view还是有可能的。

所以为了更好的辨认，可以按照变量的具体作用来划分，就比如上述的例子，可以简单的划分为 topDatas,bottomDatas,也可以是bookDatas,subBookDatas等。

百度一下,你就知道(拼音型命名/强行缩写型命名)

对于一些初入行的,尤其是那些英语水平一般的童鞋。有的时候找不到一个合适的英文组合来命名，这个时候可能为了好记(相比之下),就采取的怕拼音的方式命名。拼音命名这可能跟我们的拼音刚好是英文字母有关系吧！

当然这肯定是不推荐的，就算是国内，绝大部分的程序员还是习惯英文命名，shenchengriqi 这么一个命名估计大部分程序员都会瞬间爆炸吧。
况且现在这个社会，翻译工具这么发达,generationDate这种直译的单词都更容易理解。

另外还有一些人命名时习惯性的缩写，比如生成日期根据用户ID,直译的话 generationDateByUserId 有的人一看太长了，不美观，于是就缩写成genDataById 短是短了，可是词不达意了。

更合适的方式可以是

1. 换个词语 createDataById
2. 通过参数来界定 generationDate(id)
3. ..其他

给每个概念定义一个词

给每个抽象的概念定义一个词，并一直保持下去。

什么意思呢?我相信应该会有不少人在进行网络请求的时候会想,我是用requestDatas呢？还是fetchDatas呢？亦或者干脆getDatas得了，甚至可能会因为request看着太熟悉了，想着换个词语来表达获取数据的意思。

一个概念对应着多个词语，这种做法显得有些可笑。不管是你自己还是与你共同协作的人都会因为这种情况而做无用功。

从现在开始，你就应该学会给每个概念定义一个显而已懂的词语。

最后给出我自己在编码过程中的一些命名规范

Android 下资源文件的命名规范

drawable下:

图标:icon_xxx
背景:bg_xxx
图片:img_xxx
选择器:select_xxx

layout下:

activity_xxx
frag_xxx
dialog_xxx
view_xxx

颜色:

颜色渐变
color_white_1   #fff
color_white_2   #333
color_white_3   #666
color_white_4   #999

多色调 res目录下建立一个color文件夹
text_white_gray
text_white_yellow