代码格式不可忽略，必须严肃对待。代码格式关乎沟通，而沟通是专业开发者的头等大事。（每种语言基本都有它自己的推荐标准，比如PHP的PSR代码规范，对格式做了详细的定义）
《代码整洁之道》Clean Code A Handbook of Agile Software Craftsmanship 读书笔记
格式
- 格式目的
- 代码格式不可忽略，必须严肃对待。代码格式关乎沟通，而沟通是专业开发者的头等大事。（每种语言基本都有它自己的推荐标准，比如PHP的PSR代码规范，对格式做了详细的定义）
- 垂直格式
- 单文件。书中的建议是，单文件的代码量不易过大。短文件通常比长文件易于理解。
- 向报纸学习。向报纸那样条理清晰，结构明确，名称一目了然。
- 概念间垂直方向上的区隔。几乎所有的代码都是从上往下读，从左往右读。每行展现一个表达式或一个子句，每组代码行展示一条完整的思路。这些思路用空白行区隔开来。
- 垂直方向上的靠近。如果说空白行隔开了概念，靠近的代码行则暗示了它们之间的紧密关系。所以紧密相关的代码应该相互靠近。
- 垂直距离。除非有很好的理由，否则就不要把关系密切的概念放到不同的文件中。（方便分析代码的执行过程，追溯某个变量或函数的继承链条）
- 垂直顺序。一般而言，我们想自上向下展示函数调用依赖顺序。也就是说，被调用的函数应该放在执行调用的函数下面。这样就建立了一种自顶向下贯穿源代码模块的良好信息流。
- 横向格式
- 水平方向上的区隔与靠近。我们使用空格字符将彼此紧密相关的事物连接到一起，也用空格字符把相关性较弱的事物分隔开。
- 水平对齐。关于代码格式尽力对齐一组声明中的变量名，或一组赋值语句中的右值。（作者不喜欢这种对齐的格式，本人比较喜欢统一对齐，这样代码看起来更清晰）
- 缩进
- while或for语句的语句体为空。如果无法避免，就确保空范围体的缩进，用括号围起来。
- 团队规则。每个程序员都有自己喜欢的格式规则，但如果在一个团队中工作，就是团队说了算。
对象和数据结构
- 数据抽象
- 隐藏实现并非只是在变量之间放上一个函数层那么简单。隐藏实现关乎抽象！类并不简单地用取值器和赋值器将其变量推向外间，而是暴露抽象接口，以便用户无需了解数据的实现就能操作数据本体。
- 数据、对象的反对称性
- 在任何一个复杂系统中，都会有需要添加新数据类型而不是新函数的时候。这时，对象和面向对象就比较合适。另一方面，也会有想要添加新函数而不是数据类型的时候。在这种情况下，过程式代码和数据结构更适合。
- 得墨忒耳律
- 模块不应了解它所操作对象的内部情形。对象不应通过存取器暴露其内部结构，因为这样更像是暴露而非隐藏其内部结构
- 数据传送对象
- 最为精炼的数据结构，是一个只有公共变量、没有函数的类。这种数据结构有时被称为数据传送对象，或DTO(Data Transfer Objects)。
- 对象暴露行为，隐藏数据
- 便于添加新对象类型而无需修改既有行为，同时也难以在既有对象中添加新行为。数据结构暴露数据，没有明显的行为。便于向既有数据结构添加新行为，同时也难以向既有函数添加新数据结构。（这地方说的比较绕，其实就是关于面向对象和面向过程的结构的维护性和选择性）
错误处理
- 使用异常而非返回码
- （书中建议使用try而非返回错误代码，这样能保持代码的整洁和美观。这个跟项目需求而定）
- 先写Try-Catch-Finally语句
- 使用不可控异常
- (这个了解的不多啊！首先说一下什么是可控异常，书中有一句描述 “每个方法的签名都列出它可能传递给调用者的异常”，个人理解就是将可能发生的异常都提前定义出来。但是。可控异常违反开放/闭合的原则。如果你在方法中抛出可控异常，而catch语句在三个层级之上，你就得在catch语句和抛出异常处之间的每个方法签名中声明该异常。这意味着对软件中较低层级的修改，都将波及较高层级的签名。修改好的模块必须重新构建、发布，即便他们自身所关注的任何东西都没改动过)
- 给出异常发生的环境说明
- 依调用者需要定义异常类
- 定义常规流程（涉及到了一个特例模式，以后研究）
- 别返回NULL值
- 别传递NULL值
