代码整洁之道(Clean Code) 笔记(二)

第四章：注释

1. 别给糟糕的代码加注释 -- 重新写吧
2. 什么也不会比乱七八糟的注释更有本事搞乱一个模块。什么也不会比陈旧，提供错误信息的注释更有破坏性
3. 若编程语方足够有表达力，或者我们长于用这些语方来表达意图，就不那么需要注释 -- 也许根本不需要
4. 注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败。注释总是一种失败
5. 不准确的注释要比没注释坏得多。它们满口胡言。代码，只有代码能忠实的告诉你它做的事
6. 好注释不多，如法律信息，警示等。我都不觉得 TODO 是多好的东西
7. 大多数注释都是坏注释，甚至一些 IDE 自动生成的代码也加一堆的废话注释，分散阅读注意力。我也写过那种日志式注释，这本是版本控制系统干的事。
8. 很奇怪 IntelliJ IDEA 还在自动为新建的类加下创建者，代码是团队共有，时间长了根本就与作者无半毛关系。我经常碰到这种写有作者的代码哭笑不得，直接把原作者改了或删了也不太好，还不如把文件删了，新建一个没有作者注释的类
9. 直接把代码注释掉是种讨厌的做法，自己可能不会再启用，其他人以为很重要更不敢删。不用了最好果断删掉，版本控制系统会帮你记住历史。
10. 个人认为，注释会胡说八道，产品代码和测试代码不会撒谎。有功夫写注释还不如写好测试用例，测试需要维护，它本身就是最真实的文档。

第五章：格式

1. 代码格式很重要，不可忽略，须严肃对待。代码格式关乎沟通，而沟通是专业开发者的头等大事。一个团队要有一致的规则
2. 代码中的空白行是一条线索，标识出新的独立概念。自上往下读代码时，目光总会停留于空白行之后那一行
3. 相应的，靠近的代码行暗示了它们之间的紧密关系，紧密相关的代码应该互相靠近。所以被废话注释隔断的变量声明不好读
4. 实体变量: 在类的顶部声明，设计良好的类的实体变量应该是被大多数方法所用。
5. 相关函数: 一般是调用者在前，被调用者在后，这符合由表及里的阅读习惯，在看到调用了别的函数时也深信它很快就会出现
6. 代码行应该要短小，宽度已不在拘泥于 80 个字符，可以规定为 100, 或 120。我的规则是 120 的字符一行，虽然现在普遍用的大显示器一屏放下 300 多个字符都没问题，但超过 120 就不好阅读了

第六章：对象和数据结构

本章内容不多，围绕着两个概念：数据结构与对象。简单讲数据结构就是 JavaBean, 私有属性配上 getter/setter 方法毫无秘密可言，与公有属性没什么差异。数据结构会有一种贫血与充血模型。对象应该尽可能的隐藏内部细节，私有变量加公共方法。

第七章：错误处理

1. 不支持异常的语言中，一般要么用返回值表示错误状态，真正的返回值得靠出口参数了; 或者是每次调用后用 getLastError() 来检查上次调用状态，总之让程序不够流畅(是的，我现在很喜欢用流畅--fluent 来要求代码的可读性)
2. 执行 try-catch-finally 语句中 try 部分的代码时，是在表明可随时取消执行，并在 catch 语句中接续。try 代码块就像是事务。 
3. Java 独创性的引入了需检测异常(checked exception), 用方法签名告知调用者可能发生的异常，以求代码更稳固，可是非但未获得好处，反而代码更高。
4. Checked exception 严重的破坏了开闭原则，它要求调用者要么再次声明要么捕获所声明的异常，这意味着对软件的较低层级的修改，将波及到较高层级的整个调用链，封装被打破了。既然异常旨在让你能在较远处处理错误，而 checked exception 却迫使它的最近调用者处理异常
5. 因为这一臭名昭著的 Checked exception, Spring 花了很大精力把 checked exception 转换成了 unchecked exception。例如 SQLException 到 DataAccessException 等
6. 不要让异常打断了业务逻辑，也不要在 catch 或 finally 块中处理业务逻辑，应该只做恢复或善后处理工作
7. 关于方法返回值一般都避免 null 值，可以用空集合或空数组，但对于返回对象的话可以选择 Java 8 的 Optional。个人认为符合业务含义时应该返回 null, 例如对输入字符串 null 无须处理时就直接返回 null
8. 那针对方法输入的 null 值如何处理呢？首先回答一个问题是能否接受 null 值，回答否的话直接断言失败，能接受 null 的话可采用 Optional 技术处理。切记勿因 null 值而隐藏的错误，也不应以 Optional 作为方法参数