《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里的都抽成函数
• 错误处理也是一件事情
• 消除代码重复 ：
  面向对象编程，面向组件编程，也都是在消除重复

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