代码整洁之道（一）
2017-11-07至2017-11-08
前言
我为什么会想买这本书？？理由很模糊，却又很简单——为了更加简洁优美的代码。然而简洁优美的代码总是很少的，至少在我目前完成的一些项目中，无论是我还是队友，对于代码的整洁与规范都没有一个明确的认识，这也是我所厌恶的现状。作为一个准程序猿，我想是时候去改变这一切了。It’s time to change!
第零章 自己写的
下面的各个大标题是原文标题，而小标题有原文，也有是本人自己总结的，当然很大程度上借鉴了原文，如有不周，敬请指正。
第一章 整洁代码
第一章前言：阅读本书有两种原因：第一你是程序员；第二，你想成为更好的程序员。很好。我们需要更好的程序员。
1.1 整洁与混乱
第一章的话没有过于深入的讲解，不过却向我们灌输了 “我们需要整洁代码” 的思想。我们需要的代码，应该是整洁的代码。可能有时为了赶工，我们需要更快地产出大量代码，但我们要铭记，代码时刻需要保持整洁，不然混乱的代码只会大大降低你的效率。
也许你也有过这样的经历：这段代码我有空回来就改得好一点。不存在的！！不是你有没有空或者回不回来的问题，很可能你早就忘了自己赶工写了一段垃圾代码或者早已忘记当时的思路是怎么样的了，因为你写的，恕我直言。。还是不说了。反正看到这一段时，我是真的笑了，好像看到了几个月前在赶比赛的自己X_X
怎么说，读了这本书，我们就入了Martin的整洁代码派了。帮派规定：让营地比你来时更干净。
第二章 有意义的命名
这章主要讲的是我们最常见的命名，往往我们的主观随意性会让我们忽视一个优秀命名的重要性，反正看完这一章，感觉Martin给我了一记当头棒喝，感觉美滋滋。
2.1名副其实
内容写的很多，其实总结一下就是：无论变量名还是方法名，都应该尽量能一眼看出来是干什么用的。比如int d，不看上下文，你根本不知道是什么，但是写成int elapsedTimeInDays你就知道是消逝的时间，很显然这就是名副其实的作用。当然，像一些状态值1、2、3、4什么的，可以给它们一些简单明了的名字，如FLAGGED等。
我的理解就是，可以让人不用看注释就能看懂的变量或者函数名，就是一次极端优秀的命名！！
2.2避免误导，做有意义的区分
本来是两章，我合在一起了。因为我感觉这两者是有关联的，甚至可以说好像讲的是一件事。
避免误导其实可以遵循以下几点：
- 别用List等对程序员有特殊意义的词
- 别使用不同之处很小的名称
- 别用该死的l和o和0和1和O
第一点很清晰，第二点给个例子XYZContrillerForEfficientHandlingOfStrings和XYZContrillerForEfficientStorageOfStrings……想必没什么好说的了。第三点,额，你自己看着办吧。。
有意义的区分注以下几点：
- 避免使用数字系列的命名，如a1,a2…
- 少说废话
针对第一点，取个好名字吧。。少说废话的话，就像a、an和the，在很多时候都是废话，而在变量后面加个info或者data，好像也并没有什么卵用=.=
总结一下，避免歧义，写写清楚，少说废话。。
2.3使用读得出来易搜索的名称
读得出来的名字怎么说，就是尽量写完整单词，缩写也尽量使用比较常见的。其实也可以这么理解，不要用一些你自创的或者自以为的简写来命名，不然就是holy shit！
可搜索的名称更常见于变量命名，比如我想找数字5，使用搜索工具估计要在一个函数里面找个半天，但是如果我命名为WORK_DAYS_PER_WEEK，可以说是很快就能找的，也符合我们2.1所说的名副其实。
2.4避免使用编码
这里的编码指的是对命名的编码，也可以说是一种规范，但是Martin极力反对使用编码，因为编码无疑要求程序员掌握另一种语言，这完全就是一种负担，而且也不利于发音。这里Martin指名道姓地指出了几种编码：
1. 匈牙利命名法
2. 成员前缀
3. 接口和实现
匈牙利命名法的规则是：属性+类型+对象名称。听说是一位匈牙利的大兄弟搞出来的，思想还不错，至少保持了命名统一，但是我查了一下百科，发现要记的缩写太多了，不想记。。
成员前缀指int xxx_m,m_xxx之类的，你用下划线命名法倒是另说，如果是单字母的命名，几乎是无意义的，旧代码的标志物而已。
接口与实现是指这是一个接口，但你命名的时候最好不要带I来标记它是一个接口。这点来说，我并不是特别赞同作者的观点，确实有待斟酌。
2.5取个好名
取个好名有很多要求，要求如下：
1. 避免思维映射
2. 别扮可爱
3. 类名应该是名词或名词短语
4. 方法名应该是动词或动词短语
5. 每个概念对应一个词
6. 别用双关语
7. 使用解决方案领域的名称
接下来，就提到了取名的诸多技巧以及忌讳。
第一点，是指程序员不应该把自己拥有的特殊知识转化成为变量名，就比如你知道傅里叶变换，那应该取名为Fourier而不应该叫做F。第二点，别扮可爱也说的是类似的事，作者就举了HolyHandGrenade与DeleteItems的例子。好吧，我知道神圣手雷很有破坏性，因为我玩过《百战天虫》。。
第三和第四点其实倒是颇有些文学方面的语法感在里面，类确实是应该一个名词，方法确实应该是一个动词，没毛病。
第五点，每个概念对应一个词，就好比fetch、retrieve、get都是取的意思，controller、manager、dirver 又好像都有驱动管理的意思。请你选择一个进行使用，朝三暮四不是好习惯啊O_O。
第六点，别用双关语，其实作者也是想让我们表述清楚，add到底是insert还是append，这点虽说没有那么发人深省，但是遵循一下还是不错的。
第七点，使用解决方案领域的名称。与其使用代码涉及领域的专有名词，不如直接使用计算机相关的专业名词比较靠谱，毕竟读你代码的肯定都是程序员。
2.6有意义的语境
Martin在语境这里的意思是，我们在某个较小的范围内，使用语境是很有必要的。比如，我有一个地名，那么state在地名这里是很清楚的，它表示的是所属洲，但是在外面就不清楚它是干什么用的了，所以我们可以将其命名为addressState。
没意义的语境就是你这个语境太广了，可有可无。就好比我ofo单车手机APP的代码，每个变量前都有ofo，这就毫无意义。
结语
其实就是第一、第二章的结语啦。第一章其实只是灌输一个思想，第二章讲解了Martin取名的一些个人经验，当然经验之谈，我认为“尽信书，则不如无书”，很多观点很棒，但是也要借鉴着来。我就爱按自己的套路来，不是不可以，但是如果你觉得Martin的做法比你优秀，我就觉得是可以借鉴一下的。
这里我也立下一个Flag，今年争取把整本书的玄学部分看完，顺带着把我的点名小软件给重构一下。大概看两章写个总结吧，也让大家能够了解一下这本书。。