《Clean Code》

image.png

之前有看到同学写到自己看了《Clean Code 》这本书的感受，他说看完这本书基本没有什么收获，这本书适合那些已经很有工作经验的人看，可是那些老人们又总是推荐新人来看这本书，这就让人很费解。不过，不同人之间会因为知识背景以及理解和领悟能力不同，对同一事物有不同的感受。那我一向是那种不会拿别人的感受当结论的人，那看这本书到底给人的感受是什么，我还是打算自己亲自去一探究竟。

什么是整洁代码？

一些经验丰富的程序员认为：

优雅高效

有意义的命名

只提供一种而非多种做一件事的途径

尽量少的依赖关系

精致和简单的代码。

那么我认为整洁的代码应该是：干净的，风格统一的，命名语义化的，逻辑结构清晰的，代码块短小简单精致的。

整洁代码的意义？

易于阅读理解、重构, 整洁的代码也是质量的保证，让别人一目尽览，而非殚精竭虑的研究。

第一章：整洁代码

让营地比你来时更干净

糟糕的代码的代价：糟糕的代码到最后难以维护和管理，会毁了项目，甚至公司。
发现糟糕的代码及时修正，因为很有可能：稍后就等于永不
整洁代码应该是：
- 能通过所有的测试
- 没有重复代码
- 包括尽量少的实体，比如类、方法、函数等
- 有意义的命名是体现表达力

第二章：有意义的命名

名副其实：一个好的名字就能体现它的功能，就能轻易知道它做了什么
避免使用误导的名字：
- 使用表意的名字
- 不要在名称中出现容器类型名，如不要有accountList这样子的
```
 反例： accountList 、BunchOfAccount
 正解：accounts
```
- 不要使用非常相似的命名,即不同之处较小的名称

命名之间做有意义的区分

反例：
Product类、ProductData类 、 ProductInfo类
theMessage、message
Data , Info就像a、 an、the一样，是意义含混的废话，废话丢失冗余
这样的虽然它们的名称不同，意思却无区别，无法区分它们的意思

命名时加上【明确的约束】加以区分和其它变量的不同之处

使用可读的单词命名
- 不要自造不存在或者奇奇怪怪的词
- 使用恰当的英语单词
避免思维映射
- 一般使用解决方案领域术语，而不是问题领域术语 (这个感觉还是有点费解的)
类名、对象名应该是【名词或者名词短语】
函数名应该是动词或者动词短语，如加上get、set、is前缀

别用双关语：一词一意规则

不要将同一单词用于不同的目的，同一术语用于不同的概念

  举个栗子：
  有一个add方法，是增加值得作用
  还有一个add方法，是连接两个现存值来获得新值
  这样就是双关语了

  正解：
  如果是把单个参数放到群集中，应该把和这个方法叫做insert，或者append之类的

添加有意义的语境
- 良好的命名应该给读者提供语境

有名为： firstName, secondName，street，houseNumber， city，state 的变量
把它们放一起的时候，很明确是构成了一个地址。但是如果在某个方法中看见孤零零一个state变量，就一定不会推断出它是某个地址的一部分了。

正解:
* 可以添加前缀：addrFirstName，addrSecondName, AddrState等，以此提供语境，至少读者可以明白这些变量是某个更大结构的一部分。
* 更好的解决方法是：创建类名为Address 的类。

其实读了这些感觉还是有感受和收获的，原来命名还是有这个多的讲究，以前都感觉命名很痛苦，不知道从什么角度出发命名更好更合适，现在起码是有些sense的了，知道了命名的好坏之分，和命名的出发点。

对本书的感觉，其实感觉本书有些地方还是不太能理解的（不包含在本笔记中），好像作者只是一提，甚至都没有给出结论，看完就很懵逼。

第三章：函数

短小
- 20行封顶最佳
- if，else等语句块内应该是一个函数调用
函数只做一件事
每个函数中的语句都要在同一抽象层级上, 一眼就能看出来
（如果混杂不同抽象层级，会让人迷惑，读者可能无法判断某个表达式是抽象层级还是细节）
单一权责原则：？Single Responsibility Principle,SRP
开放闭合原则：？Open Closed Principle ,OCP
使用描述性的名称
- 函数的名称应该表达函数做的事情
- 命名方式保持一致，使用与模块名一脉相承的短语，名称、动词
- 函数短了也方便起名字
函数参数尽可能的短，最好不要超过三个
如果函数的参数大于等于3个，可以考虑将参数封装为对象，从而降低参数数量
函数命名：函数名和参数名能够形成可以良好的动词/名词对形式：如 AssertExpectedEqualsActual（expected， actual）
无副作用：根据函数名就知道它做的事情，函数中不应该有其他的操作
使用异常代替返回错误码
抽离try/catch: 它搞乱了代码结构，把正常流程和错误处理混在一起，应该把try 里和catch里的都抽成函数
错误处理也是一件事情
消除代码重复：
面向对象编程，面向组件编程，也都是在消除重复

待续............