《代码整洁之道》笔记

《代码整洁之道》笔记

第 1章 整洁代码

1、阅读本书有两种原因：第一，你是个程序员；第二，你想成为更好的程序员。很好。我们需要更好的程序员。
2、代码写的混乱影响项目进度。
3、整洁的代码读起来令人愉悦。

第 2章 有意义的命名

1、尽可能的使用标准命名方法，驼峰式命名
2、命名要找更有表现力的词，看得懂的词
3、类名和对象名应该是名词或名词短语，如 Customer，方法名应当是动词或动词短语，如 postPayment。
4、做有意义的区分

public static void copyChars( char a1[], char a2[]) { 
　 for (int i = 0; i < a1. length; i + +) { 
　 　 a2[ i] = a1[ i]; 　} 
}

以数字系列命名（ a1、 a2，…… aN）是依义命名的对立面。这样的名称纯属误导——完全没有提供正确信息；

第 3章 函数

1、函数不该有 100行那么长，20行封顶最好，不应该写太长
2、最理想的参数是零参数，最长不要超过三个入参，尽量不要输出参数
3、别返回或传入null，或返回特殊对象
4、函数应该只做一件事，函数单一职责

• 函数名称或者代码块的业务目标是什么
• 函数的执行步骤，抽象层次是否相同
• 如果有足够的行数在解决不相关的子问题，提取出来
• 每一行代码是否在为目标工作？如果不是，提取出来

5、使用异常代替直接返回错误码，如下面代码段。

• 可以使错误处理从主路径中分离出来，使主流程清淅易懂
• 使用错误码返回易导致深层次嵌套

try{

      deletePage( page);         
	  registry. deleteReference( page. name); 　 
	  configKeys. deleteKey( page. name. makeKey()); 
	  
} catch (Exception e) { 　
logger. log( e. getMessage());
}

6、提早返回可以减少嵌套并让代码整洁。

第 4章 注释

别给糟糕的代码加注释——重新写吧 —Brian W. Kernighan与 P. J. Plaugher

1、好的代码比注释更重要
2、注释掉的代码直接删掉，可以在git上找到
3、在类级别使用Javadoc注释来解释所有部分如何工作
4、团队版权及著作权声明注释
5、注释应申明代码高层次意图，而非明显细节
6、不要添加代码的著作人信息，git可以干的事情不要交给代码
7、好代码 > 坏代码 + 好注释
8、不准确的注释要比没注释坏得多。它们满口胡言。因为代码在变动，在演化。很不幸，注释并不总是随之变动——

第 5章 格式

1、选用一套管理代码格式的简单规则，然后贯彻这些规则。
2、变量声明应尽可能靠近其使用位置。
3、实体变量应该在类的顶部声明。
4、团队认同一种格式风格，每个成员都应该采用那种风格。
5、我觉得IDea的自动格式化可行。
6、代码行长度控制在100-120个字符

第 6章 对象和数据结构

1、将变量设置为私有（ private），不想其他人依赖这些变量。
2、得墨忒耳律规定：方法不应调用由任何函数返回的对象的方法。
下列代码违反了得墨忒耳律

final String outputDir = ctxt. getOptions()
. getScratchDir(). getAbsolutePath();

第 7章 错误处理

1、将try包含的代码块抽象成一个函数，使错误处理从主路径中分离出来，使主流程清淅易懂。
2、执行 try-catch-finally语句中 try部分的代码时，你是在表明可随时取消执行，并在 catch语句中接续。
3、在方法中返回 null值是糟糕的做法，但将 null值传递给其他方法就更糟糕了。

第 8章 边界

1、不要在生产代码中试验新东西，而是编写测试来遍览和理解第三方代码。
2、学习性测试确保第三方程序包按照我们想要的方式工作。
一旦整合进来，就不能保证第三方代码总与我们的需要兼容。

第 9章 单元测试

1、不要怕繁琐，测试名字和方法应尽量详细，测试代码一样需要整洁。
2、不要追求太高的测试覆盖率，测试代码前面90%通常比后面10%花的时间少
3、使用简单的能够完整运行的代码测试输入
4、测试代码与生产代码一样重要，整洁的测试有三个要素：可读性，可读性和可读性。
5、TDD三大定律，测试与生产代码一起编写，测试只比生产代码早写几秒钟。

定律一 　在编写不能通过的单元测试前，不可编写生产代码。
定律二 　只可编写刚好无法通过的单元测试，不能编译也算不通过。
定律三　只可编写刚好足以通过当前失败测试的生产代码。

6、敏捷和 TDD运动要求许多程序员编写自动化单元测试。
7、JUnit中每个测试函数都应该有且只有一个断言语句，断言数量应该最小化。

@ Test 　 
public void turnOnHeaterAndBlowerIfTooCold() throws Exception { 　 　 
tooCold(); 　 　 
assertEquals(" HBchl", hw. getState()); 　
}

第 10章 类

1、单一权责原则（ SRP）认为，类或模块应有且只有一条加以修改的理由。
2、系统应该由许多短小的类而不是少量巨大的类组成。每个小类封装一个权责，只有一个修改的原因，并与少数其他类一起协同达成期望的系统行为。
3、依赖倒置原则（ Dependency Inversion Principle， DIP）。本质而言， DIP认为类应当依赖于抽象而不是依赖于具体细节。
4、拓展，java类设计原则：
1依赖倒置原则
2里氏替换原则
3接口分隔原则
4单一职责原则
5开闭原则
6 迪米特法则（最少知道原则）

第 11章 系统

1、使用依赖注入实现分离对象的构造与使用，Spring框架提供了最有名的 Java DI容器。
2、使用spring AOP恢复横贯式关注面模块化。

第 12章 迭进（软件设计层面）

创建具有良好设计的软件的4条规则，优先级从高到低：
1、运行所有测试；（全面测试）
以下都属于经过测试之后重构
2、不可重复；（极其雷同的代码和实现的重复）
3、表达了程序员的意图；（代码后期维护）
4、尽可能减少类和方法的数量；（系统短小精悍）
以上规则按其重要程度排列。

第 13章 并发编程

“对象是过程的抽象。线程是调度的抽象。” ——James O Coplien

1、分离并发相关代码与其他代码。
2、采用 synchronized关键字在代码中保护一块使用共享对象的临界区（ critical section）。限制临界区的数量很重要。
3、谨记数据封装；严格限制对可能被共享的数据的访问。
4、尝试将数据分解到可被独立线程（可能在不同处理器上）操作的独立子集。
5、采用 ConcurrentHashMap实现都比 HashMap表现得好，还支持同步并发读写，也拥有支持非线程安全的合成操作的方法。
6、生产者-消费者模型，读者-作者模型，宴席哲学家。
7、避免使用一个共享对象的多个方法。
8、尽可能减小同步区域。
9、尽早考虑关闭问题，尽早令其工作正常。这会花费比你预期更多的时间。检视既有算法，因为这可能会比想象中难得多。
10、尽早并经常地在所有目标平台上运行线程代码。

第 14章 逐步改进

1、Args类逐步改进。

第 15章 JUnit内幕

1、重构是一种不停试错的迭代过程，不可避免地集中于我们认为是专业人员该做的事。

第 16章 重构 SerialDate

1、SerialDate是一个用 Java呈现一个日期的类。

第 17章 味道与启发

1、关闭某些编译器警告（或者全部警告！）可能有助于构建成功，但也存在陷于无穷无尽的调试的风险。
2、每个团队都应遵循基于通用行业规范的一套编码标准。
3、花时间明智地取名，保持名称有关。名称太重要了，不可随意对待。
4、测试边界条件。