《代码整洁之道》读书笔记

读书笔记

一、有意义的命名

1.1 名副其实

它该告诉你，它为什么会存在，它做什么事，它应该怎么用。如果名称需要注释来补充，就不算名副其实

如int d; //消逝的时间，以日计

1.2 避免误导

• 避免留下掩藏代码本意的错误线索
• 应当避免使用与本意相悖的词

如accountList，但是它本身可能不是List类型

1.3 作有意义的区分

• 不要以数字系列区分，如a1,a2
• 废话是另一种没意义的区分，如Product与ProductInfo或ProductData
• 要区分名称，就要以读者能鉴别不同之处的方式来区分

1.4 使用读得出来的名称

如genymdhis,读起来就很麻烦

1.5 使用可搜索的名称

单字母和数字常量很难在文字里找出来，而MAX_CLASSES_PRE_STUDENT就很容易

1.6 避免使用编码

即不要把类型或作用域编进名称里

1.7 避免思维映射

不应当让读者在脑中把你的名称翻译为他们熟知的名称

如r作为url的别名，ad作为address的缩写

1.8 类名

• 类名和对象名应该是名词或名词短语
• 类名不应当是动词

1.9 方法名

方法名应当是动词或动词短语，如deletePage

1.10 别扮可爱

意思就是别太幽默，别人可能不懂你的幽默

1.11 每个概念对应一个词

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

如同一堆代码又有controller，又有manager，又有driver，就会令人困惑

1.12 别用双关语

避免同一个单词用于不同的目的

1.13 使用解决方案领域的名称

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

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

如果不能用程序员熟悉的术语来给手头的工作命名，就采用从所涉问题领域而来的名称吧

1.15 添加有意义的语境

你需要有良好命名的类、函数或名称空间来放置名称，给读者提供语境

如添加前缀addrFirstName、addrLastName、addState

1.16 不要添加没用的语境

如不要在每个类名前加入项目名

1.17 总结

取好名字最难的地方在于需要良好的描述技巧和共有文化背景

与其说这是一种技术、商业或管理问题，还不如说是一种教学问题

二、函数

2.1 短小

函数的第一规则是要短小

函数不该有100行那么长，20行封顶最佳。

注：作者这本书介绍的语言是Java，其他编程语言有差异，求同存异吧，主要是体会作者的意思

2.2 只做一件事

函数应该做一件事。做好一件事。只做一件事，并且要尽量的短小。

问题在于很难知道那件该做的事是什么

要判断函数是否不止做了一件事，就是看是否能再拆出一个函数来

2.3 每个函数一个抽象层级

直顶向下读代码：向下规则

我们想要这样读程序：程序就像是一系列TO起头的段落，每一段都描述当前抽象层级，并引用位于下一抽象层级的后续TO起头的段落

2.4 switch语句

确保每个switch都埋藏在较低的抽象层级，而且永远不重复

2.5 使用描述性的名称

沃德原则：如果每个例程都让你感到深合己意，那就是整洁的代码

2.6 函数参数

用尽量少的参数，参数不易对付，它们带有太多概念性

最理想的参数是0,其次是1,再次是2.尽量避免3个。有足够特殊的理由才能用3个以上函数

2.7 无副作用

函数承诺只做一件事，就不要做其他被藏起来的事

2.8 分割指令与询问

函数要么做什么事，要么回答什么事，但二者不可兼得。

2.9 使用异常代替错误返回码

2.10 别重复自己

避免在函数中重复使用代码

2.11 结构化编程

2.12 如何写出这样的函数

写函数的一开始都是冗长复杂的，之后要用心分解函数、修改名称和消除重复

三、注释

别给糟糕的代码加注释 - 重新写吧。

唯一真正好的注释是你想办法不去写注释

3.1 注释不能美化糟糕的代码

与其花时间解释你搞出的糟糕的代码的注释，不如花时间清洁那堆糟糕的代码

3.2 用代码来阐述

3.3 好注释

• 法律信息 //有时，公司代码规范要求编写与法律有关的注释。例如版权和著作申明。
• 提供信息的注释 //这类注释有时管用，但更好的方式是尽量利用函数名称传达信息
• 对意图的注释
• 阐释
• 警示 //用于警告其他程序员会出现某种后果的注释
• TODO注释 //有理由用//TODO形式在源代码中放置要做的工作列表
• 放大 //有的代码可能看着有点多余，但编码者当时是有他自己的考虑，这个时候需要注释下这个代码的重要性。避免后面被优化掉。

3.4 坏注释

• 喃喃自语
• 多余的注释
• 误导性注释
• 循规式注释 //就是说不用每个函数都要有Javadoc，每个变量都要有注释
• 日志式注释
• 废话注释
• 可怕的注释
• 能用函数或变量时就别用注释
• 位置标记
• 括号后面的注释
• 归属与署名
• 注释掉的代码
• HTML注释
• 非本地信息 //请确保注释描述了离他最近的代码
• 信息过多
• 不明显的联系 //注释及其描述的代码之间的联系应该显而易见
• 函数头

四、格式

4.1 格式的目的

代码的格式关乎沟通，而沟通是专业开发者的头等大事

代码的可读性会对以后可能发生的修改行为产生深远的影响

4.2 垂直格式

4.2.1 向报纸学习

名称应当简单且一目了然。名称本身应该足够告诉我们是否在正确的模块中。源文件最顶部应该给出高层次概念和算法。细节应该往下渐次展开，直到找到源文件中最底层的函数和细节。

4.2.2 概念间垂直方向上的区隔

几乎所有的代码都是从上往下读，从左往右读。每行展现一个表达式或一个子句，每组代码行展示一天完整的思路。这些思路用空白行区隔。

4.2.3 垂直方向上的靠近

如果说空白行隔开了概念，靠近的代码行则暗示了它们之间的紧密关系

4.2.4 垂直距离

关系密切的概念应该互相靠近，应避免迫使读者在源文件和类中跳来跳去

• 变量声明应尽可能靠近其使用位置

• 实体变量应该在类的顶部声明

• 相关函数。某个函数调用另一个，应该把它们放在一起，并且调用者在前，被调用者在后

• 概念相关的代码应该放在一起。相关性越强，彼此之间的距离就该越短

4.2.5 垂直顺序

一般来说，我们想自上而下展示函数调用依赖顺序。即调用在前，被调用在后。

4.3 横向格式

4.3.1 水平方向上的区隔与靠近

4.3.2 水平对齐

4.3.3 缩进

依靠缩进，来判断当前代码在什么范围中工作

4.4 团队规则

同组开发人员应认同同一种代码风格，并且每个人都应遵循这种风格

六、对象和数据结构

6.2 数据、对象的反对称性

对象和数据结构之间的二分原理：
- 过程式代码（使用数据结构的代码）便于在不改动既有数据结构的前提下添加新函数。
- 面向对象代码便于在不改动既有函数的前提下添加新类。

反过来讲也成立：
- 过程式代码难以添加新数据结构，因为必须修改所有函数。
- 面向对象代码难以添加新的新函数，因为必须修改所有类。

6.3 得墨忒耳(Demeter)律

模块不应了解它所操作对象的内部情形

6.5 小结

对象暴露行为，隐藏数据。数据结构暴露数据，没有明显的行为。

在系统中，希望灵活的添加新数据类型，这时使用对象。希望灵活的添加新行为，这时使用数据类型和过程。

七、错误处理

7.1 使用异常而非返回码

7.2 先写try-catch-finally语句

7.3 使用不可控异常

7.7 别返回null值

7.8 别传递null值

八、边界

这一章介绍的是在使用第三方程序包或者开源代码的时候，如何保持软件系统边界的问题。

九、单元测试

TDD三定律：

• 除非这能让失败的单元测试通过，否则不允许去编写任何的生产代码。
• 只允许编写刚好能够导致失败的单元测试。 （编译失败也属于一种失败）
• 只允许编写刚好能够导致一个失败的单元测试通过的产品代码。

测试代码和生产代码同样重要，需要被思考、设计并且不断的修改。它应该像生产代码一样保持整洁。有了测试，你就不担心对代码的修改，没有单元测试，每次修改都可能带来缺陷。

整洁的测试三要素：可读性，可读性和可读性。

每个测试一个断言。

每个测试只测试一个概念。

F.I.R.S.T ：Fast(快速)、Independent(独立)、Repeatable(可重复)、Self-Validating(自足验证)、Timely(及时)

后面基本都看不懂了，就比较高级，好多Java的东西，过几个月再来拜读吧