代码整洁之道 5、6、7、8

第五章 格式

5.1 格式的目的
格式比内容重要，内容在以后可能被修改，而格式风格却会一直影响项目。
5.2 垂直格式
有可能使用大多数为200行，最长500行的单个文件构造出色的系统（并不是不能去使用长文件）。通常短文件比长文件易于理解

• 5.2.1 向报纸学习
  源文件顶部应该给出高层次的概念和算法。细节依次向下展开，直至找到源文件中最底层的函数与细节
• 5.2.2 概念间垂直方向上区隔
  用空白行隔开各个概念
• 5.2.3 垂直方向上的靠近
  靠近的代码反应之间的紧密关系（如：变量声明在一起）
• 5.2.4 垂直距离
  变量声明：变量声明应该尽可能靠近它的使用位置。本地变量应该在函数的顶部出现
  实体变量：应该在类的顶部声明
  相关函数
  某个函数调用另一个，应该将它们放在一起
  概念相关
  概念相关的代码应该放在一起。相关性越强，彼此的距离应该越短
• 5.2.5 垂直顺序
  自上向下展示函数调用依赖顺序。被调用应该放在调用函数的下面

5.3 横向格式
代码行长度尽力保持上限为120个字符，即IDEA的虚线位置

• 5.3.1水平方向上的区隔与靠近
  空格字符将彼此相关的事物连接在一起
  int lineSize = line.length();
• 5.3.2水平对齐
  不要水平对齐
• 5.3.3 缩进
• 5.3.4 空范围

while(dis.read(buf, 0, readBufferSize) != -1)
;```
##第六章 对象与数据结构
#### 6.1 数据抽象
具象点：

public class Point{
public double x;
public double y;
}

抽象点：

public interface Point{
double getX();
double getY();
void setCartesian(double x, double y);
double getR();
double getTheta();
void setPolar(double r, double theta);
}

第一个暴露了实现，即使变量是私有的，也能通过赋值器和取值器来使用变量。
第二个呈现了一种数据结构，固定了一种存取策略，但却对实现一无所知。
#### 6.2 数据结构、对象的反对称性
对象把数据隐藏在抽象之后，暴露操作数据的函数。
数据结构暴露其数据，没有提供有意义的函数
过程式代码便于在不改动现有数据结构的情况下添加新函数。
面向对象函数便于在不改动现有函数的前提下添加新类。
#### 6.3 得墨忒耳律
模块不应该了解它所操作的对象的内部情形。这意味着：对象不应该通过存取器暴露其内部结构。
得墨忒耳认为：类C的方法 f 应该调用以下对象的方法
* C
* 由 f 创建的对象
* 作为参数传入的对象
* 由C的实体变量持有的对象
违反该规则的代码
`final String  outputDir = ctxt.getOption().getScratchDir().getAbsolutePath()`
**6.3.1 火车失事**
上述糟糕的代码看起来像一列火车，被称为火车失事。
**6.3.2 混杂**
避免混合结构一般是对象，一半是数据结构
**6.3.3 隐藏结构**
#### 6.4 数据传送对象
只有公共变量、没有函数的类，这种数据结构称为数据传送对象
## 第七章 错误处理
#### 7.1 使用异常代替返回码
#### 7.2 先写Try-Catch-Finally语句
#### 7.3 使用不可控异常
可控异常违反了开放/关闭原则。在有一个函数抛出一个可控异常时，独有调用该函数的函数都需要抛出该异常
#### 7.4 给出异常发生的环境说明
抛出的每个异常，都应该提供足够的环境说明，以便判断错误的来源和处所。
#### 7.5 依调用者需要定义异常类
#### 7.6 定义常规流程
#### 7.7 别返回null值
#### 7.8 别传递null值
null判断
## 第八章 边界
#### 8.1使用第三方代码
在接口提供者和使用者之间存在与生俱来的张力。提供这追求普适性，能够在多个环境中工作；使用者则想要在满足特定需求的接口。这种张力就会在系统边界上出问题。
如：Map，我们希望接收者不要删除映射图的任何东西，但Map却提供了clear方法
#### 8.4学习型测试的好处不只是免费
学习性测试是一种精确实验，帮助我们对API的理解。
#### 8.5 使用上不存在的代码
存在一种边界，将已知和未知分割开的边界。我们有时候不要去向边界那边望过去
#### 8.6 整洁的代码
对于控制不了的代码，我们需要花费时间去小心投资，确保未来的修改不会代价太大