[笔记]代码整洁之道

[笔记]代码整洁之道

代码整洁

1.能通过所有的测试。--------------------------------高效、易维护
2.没有重复代码。-----------------------------------------------重复性
3.体现系统中的全部设计理念。-----------------------------明确性
4.包含尽量少的实体、比如类、方法、函数等 -------减少依赖

命名

1.名副其实

从名字能够清楚意义。

2.避免误导

不是string类型却使用xxstring来命名。

3.减少模糊以便区分

eg：
variable—不应使用
customer&customerobject—不易区分

4.便于搜索

单字母的变量名仅用于短方法中的本地变量。名称长短应与其作用域大小相对应。

5.功能命名

eg：
类名应为名词或短语+驼峰(首字母大写)
方法名应为动词或动词短语

6.单一对应

每个概念对应一个词，并且从始至终。

函数

1.短小
2.只做一件事+做好这件事
3.参数少
4.不重复

注释

带有少量注释的整洁而有表达力的代码，要比带有大量注释的零碎而复杂的代码像样的多。

作者认为好的注释包括以下几个方面：
1.法律相关信息
2.功能作用的解释
3.引起注意

格式

纵向格式：

1.函数与函数之间留空行。
2.变量声明：变量声明应该尽可能靠近其使用位置。因为函数很短，本地变量应该在函数的顶部出现。
3.实体变量应在顶部，会被使用的多。
4.相关函数，被调用者放在调用者的上面。
5.“相关概念的代码放在一起。相关性越强，比如一个大功能逻辑靠在一起。”

横向格式

1.一行的长度
2.复制语句两端留空
3.不在函数名和左括号间加空格，因为函数与其参数密切相关。
4.缩进

对象和数据结构

1.过程式代码（函数编程）便于在不改动既有数据结构的前提下添加新函数，面向对象代码便于在不改动既有函数的前提下添加新类。反过来讲也说的通,过程式代码难以添加新的数据结构，因为必须修改所有函数，面向对象代码难以添加新函数，因为必须修改所有类。所以在设计的时候要分析好是以后是要添加新函数还是要添加新的数据结构。
2.德墨忒尔律：模块不应该了解它所操作对象内部情形。

异常处理

1.使用try语句
抽离try语句，try里面的语句尽可能少
2.根据需要定义异常类。
3.不返回null值。

边界

1.对第三方进行学习性测试，当第三方程序包发布了新的版本，我们可以允许学习性测试，看看程序包的行为有没有发生改变。

2.使用尚不存在的代码，有时候我们的第三方，还没有开发好API，但又不能影响到我们的开发进度，所以我们先可以定义好自己想要的接口。如果第三方ok了，我们再对接起来。
3.通过接口管理第三方边界，可以使用ADApter模式将我的接口转换为第三方提供的接口。这个是要注意，第三方的代码和自己的代码混合太多，这样不便管理。

单元测试

敏捷和TDD运动鼓舞了许多程序员编写自动化单元测试，单元测试是确保代码中的每个犄角旮旯都如我们所愿的工作。
TDD三定律
除非这能让失败的单元测试通过，否则不允许去编写任何的生产代码。
只允许编写刚好能够导致失败的单元测试。 （编译失败也属于一种失败）
只允许编写刚好能够导致一个失败的单元测试通过的产品代码。

PS:什么是生产代码
  测试代码和生产代码一样重要，它可不是二等公民，它需要被思考、被设计和北照料。它该像生产代码一样保持整洁。单元测试让你的代码可扩展，可维护，可复用。原因很简单，有了测试，你就不担心对代码的修改，没有单元测试，每次修改可能带来缺陷，一个测试，一个断言。一个测试，对应一个概念。我们不想要超长的测试函数。

测试还应遵守以下5条规则
1.快速 测试应该能快速运行，太慢了你就不会频繁的运行，就不会尽早的发现问题。
2.独立。测试应该相互独立，某个测试不应该为下个测试设定条件。当测试相互依赖，一个没通过导致一连串的测试失败，使问题诊断变的困难。
3.可重复。测试应该可以在任何环境中重复通过。
4.自足验证 测试应该有布尔值输出，无论通过或失败，不应该是查看日志文件去确认
5.及时。单元测试应该恰好在使其通过的生产代码之前编写。

类

1.类应该短小
2.单一权责原则(SRP)：类或模块应有且只有一条加以修改的理由。系统应该有许多短小的类而不是巨大的类组成。

 PS：每个达到一定规模的系统都会包括大量逻辑和复杂性。管理这种复杂性的首要目标就是加以组织，以便开发者在哪儿能找到东西，反之，拥有巨大、多目的的类的系统，总是让我们在目前并不需要了解的一大堆东西中艰难的跋涉。

3.内聚：如果一个类中的每个变量都被每个方法所使用，则该类具有最大的内聚性。内聚性高，意味着类中的方法和变量相互依赖，相互结合成一个逻辑整体。
4.为了修改而组织。开放闭合原则（OCP）：类应当对扩展开放，对修改封闭。我们可以借助接口和抽象类来隔离这些细节带来的影响。

系统

1.抽象为工厂模式：将构造的细节隔离于应用程序之外。
2.依赖注入。
3.扩容。
4.免洗那个切面编程。

迭进

1.运行所有测试。
2.重构：消除重复，保证表达力，尽可能的减少类和方法的数量
3.不可重复

并发编程

模型
生产者-消费者、读者-写者、哲学家