Java进阶之路【代码篇】——《CleanCode》编程规则精编（1）命名

阅读本文之前请确保你已与我达成共识。即，代码是一门讲规矩的艺术。

前一段时间因为要参加一个有关重构的培训，匆匆读完了《CleanCode》一书，参加完培训后看到之前的读书笔记，发现又有了一番新的认识，因此在此加以总结。希望能够与愿意把代码当成一件艺术品去精心打磨的同学们一起来学习和研究如何把代码写的“优雅”。
简洁优秀的代码的好处不需更多的解说，但如何写出“优雅”的代码，还需要在个人的实践中仔细的体会吧。

在这里我把自己在《CleanCode》一书中认为赞同或反对的观点列举出，加以解读。一方面希望能够让自己更深入的去思考这些问题，同时也把自己思考的结果分享出来。对于某项观点不甚赞同或是想深入了解的同学，建议亲自读一读《CleanCode》这本书，里面的内容和观点不一定全对，但足够引发我们关于写出优雅代码的一些思考。

下面开始正文，另:章节目录其实就是有关命名的几大核心规则,基本覆盖CleanCode的全部目录项并加以分类。如果通读目录发现每一项原则都已理解，那就请移步别处吧，别再浪费时间。时间宝贵，程序员的时间更加宝贵。

有意义的命名

有关命名的问题中，有一个根本的观点就是：命名一定要有意义，能够直观了当的表达出被命名对象的实际含义。

名副其实

变量、函数、类的名字应该是自解释性的

书中有一个很直白的标准可以用来衡量是否符合这个要求

如果名称需要注释来补充，那就不算是名副其实

如果你写完了一个变量、函数或者类，你立刻就感觉自己需要写一段注释以免其他人看不懂，或者是自己看不懂。那么就应当考虑修改自己刚刚起的名字，而不是组织注释的语言了。

---

避免误导

有以下几种情况有可能导致词汇产生误导性

1. 使用了多义词，因单词的多种含义引起误导
2. 名字没有表达清楚变量、函数、类的具体含义，引发误导
3. 变量、函数违反“单一权责原则”，代表了多个含义，具有多个功能，因此针对其中的一个功能而起的名字，就产生了误导。
4. 上下文不一致
   《CleanCode》一书中特意强调了第4点的重要性，这一点也是我们大多数人从来没有想过的一个问题。即，上下文中、甚至是一个系统中，一类操作都应该被赋予相同的名字。如果你在一端代码中读到了两个方法，一个叫removeXxx，一个叫deleteXxx。尽管他们的字面含义相同，但你是否也会认为这两个方法的功能有所差别呢？

拼写前后不一致就是误导

每个概念（只）对应一个词

给每个抽象概念选一个词，并且一以贯之

别用双关语

不要使用可能包含多种含义的词来进行命名

---

避免冗余

做且只做有意义的区分

不要在名字中加入一些毫无意义的废话。这句话貌似有点语病，但的确是为了强调，停止那些可笑的规则吧，没有必要在名字中加入那些东西。成员变量 instance 不需要命名为 _instance来代表它的作用域，一个Person实体类的name成员也没有必要命名为cName来表示Person的名字是char型的，难不成Person的name还能是浮点型的？一个叫做Machine的类，，它的方法不需要命名为 startMachine,stopMachine,resetMachie,类中还有其他的类似方法可能引起混淆？这说明Machine类该重构了。

另外一点，尽量不要在名字中出现数字。代码中的Magic Number我们都要一一抹杀掉，更何况是命名当中的呢？

避免编码

同“做有意义的区分”一段的内容，原书中的观点是：

• 没有必要把数据类型编入变量
• 不需要使用特殊的标记来标识成员变量
• 没有必要在接口的前面加I

第三点吧，显得有些绝对。但是我本身也是非常讨厌在接口前面加I、在抽象类前面加Abstract的，这种修饰词加与不加对于整体代码的可读程度并不会有什么影响吧？这个观点就因人而异吧。

---

要直接

避免思维映射

取的名字，不要让人再思考一遍才能明白含义。包括需要引申的思维映射，以及需要反义的思维映射。男厕所就叫男厕所，不要叫非女厕所。也不要用一些只用少部分人才知道的梗，知道这个梗的人看到你的命名说不定会心领神会的一笑，可不懂你梗的人会想，天知道这是什么鬼？

明确是王道

使用可读出来的名字

作者在书中举了一个很有趣的例子，具体内容记不清楚了。但是大致意思就是，写代码毕竟不是一个人的事情，名字如果起的很奇怪，这让大家如何去讨论呢？
比如，一个StringBuffer对象可以起名为 buffer、sbuffer（忽略其实际含义的情况下），何苦非要起名为sb……搞得大家讨论的时候对你说，你这个sb用的有点问题，这里……

使用可搜索的名字

大家都是在现代IDE上做开发，起个容易搜索的名字，alt+shift+/的时候，你好我也好。在这里作者有一个观点，值得讨论：

名字长短应与其作用域大小相匹配

即，作用域大的变量，就不要取一个短小的名字，以免因为复杂的上下文导致这个名字的含义发生某些改变。但是作用域小的变量，比如某个循环中的临时变量，取个I、j、k、t是完全没有问题的。

---

基本规则

类名应当是名词或名词短语

方法名应当是名词或名词短语

没有那么绝对，但有一定道理。当然各种例外一定是存在的，但是在起名的时候可以用作参考。我的类是否能命名成名词或名词短语，如果不能，那么是为什么？是不是因为我的类中包含某些本应属于其他类的方法？是不是过于依赖某个类了？这就需要看具体情况加以思考了。

添加有意义的语境

可以通过添加语境(适当增加前缀、用类封装)的方式来增强名称的自解释性

不要添加没用的语境

只要短名称足够清楚，就要比长名称好

业务方面

使用解决方案领域名称

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

使用程序员能看懂的词
使用与系统业务相关的词汇

记住，只有程序员才会读你的代码

总结

时刻记住，代码首先是写给人看的，其次才是编译执行的。写机器能运行的代码简单，但写人能看懂的代码，却并非易事。

写出人人都看不懂的代码，并不牛逼，写出人人都能看懂的代码，那才是牛逼。

感觉被骗了，想看真正的总结？回去看一眼目录吧，那就是最好的总结了。不然要目录干啥呢？