一、什么是整洁代码
我喜欢优雅和高效的代码，代码逻辑应当直截了当，叫缺陷难以隐藏；尽量减少依赖关系，使之便于维护，依据某种分层战略完善错误处理代码；性能调至最优，省得引诱别人做没规矩的优化，搞出一堆混乱来，整洁的代码只做好一件事
---- Bjarne Stoustrup
1.简洁代码规则：
1.能通过所有测试；
2.没有重复代码；
3.体现系统总得全部设计理念；
4.包括尽量少的实体，比如：类、方法、函数等
2.命名
1、名副其实
2、避免误导
3.做有意义的区分
4.使用读得出来的名称
5.使用可搜索的名称
6.避免使用编码
6.1 匈牙利语标记法
6.2 成员前缀
6.3 接口和实现
7.避免思维映射
8.类名
类名和对象应该是名册或名词短语
9.方法名
方法名应当是动词或者动词短语
10.别扮可爱
11.每个概念对应一个词
12.别用双关语
13.使用解决方案领域名称
14.使用院子所涉问题领域的名称
15.添加有意义的语境
16.不要添加没用的语境
3.函数
函数规则：
1.短小
代码块和缩进
2.只做一件事
函数应该做一件事，做好这件事，只做一件事
3.每个函数一个抽象层级
自顶向下读代码：向下规则
4.switch 语句
switch 的优化
5.使用描述性的名称
别害怕长名称，长而具有描述性的名称，要比短而令人费解的名称好
6. 函数参数
尽可能减少函数参数
4.格式
一组开发者应当认同一种格式风格，并作为规则执行
5.对象和数据结构
1.数据抽象
2.数据、对象的反对称性
过程式代码便于在不改动既有数据结构的前提下添加新函数，面向对象代码便于在不改动既有函数的前提下添加新类
3.得墨忒耳律
著名的德墨忒耳律认为，模块不应了解它所操作对象的内部情形
4.数据传送对象
最为精练的数据结构，是一个只有公共变量、没有函数的类。这种数据结构有时被称为数据传送对象，或者DTO
6.错误处理
1.使用异常而非返回码
2.先写Try-Catch_Finally语句
异常的妙处之一是，它们在程序中定义一个范围，执行try-catch-finally语句中try部分的代码时，你是在表明可随时取消执行，并在catch语句中接续，在某种意义上，try代码块就像是事务，catch代码块将程序维持在一种持续状态，无论tru代码块中发生了什么均如此。所以，在编写可能抛出异常的代码时，最好先写出try-catch-finally语句，这能帮你定义代码的用户应该期待什么，无论trt代码块中执行的代码出什么错都一样
3.给出异常发生的环境说明
你抛出的每个异常，都应当提供足够的环境说明，以便判断错误的来源和处所
4.以调用这需要定义异常类
对错误分类有很多方式，可以依其来源分类，不过，当我们在应用程序中定义异常类是，最重要的是考虑它们如何被捕获
5.定义常规流程
如果你遵循前文提及得我建议，在业务逻辑和错误处理代码之间就会有良好的区隔，大量代码会开始变得像是整洁而简朴的算法
6.别返回null值
7.别传递null值
7.边界
1.使用第三方代码
在接口提供者和使用者之间，存在与生俱来的张力，第三方程序包和 快那个价提供者追求者普适性，这样就能在多个环境中工作，吸引广泛的用户，而使用者则想要集中满足特定需求的接口，这种张力会导致系统边界上出现问题
2.整洁的边界
边界上会发生有趣的事，改动是其中之一，边界上的代码需要清晰的分割和定义了期望的测试，应该避免我们的代码过多的了解第三方代码中的特定信息，依靠你能控制的东西，好过依靠你控制不了的东西，免得日后受它控制
8.测试
1.TDD三定律
1.在编写不能通过的单元测试前不可编写生产代码
2.只可编写刚好无法通过的单元测试，不能编译也不算通过
3.只可编写刚好足以通过当前失败测试的生产代码
2.保持测试整洁
可读性、
3.每个测试一个断言
junit 每个测试函数都应该有且只有一个断言语句，这条规则看似过于苛刻，但好处颇多
9.类
1.类应该短小
2.单一权责原则
类或模块应有且只有一条加以修改的理由
3.内聚
类应该只有少量实体变量，类中的每个方法都已操作一个或多个变量，通常而言，方法操作的变量越多，就越粘聚到类上，如果一个勒种的每个变量都被每个方法所使用，则该类具有最大的内聚性，一般来说，创建这种极大化内聚类是几步可取也不可能的；另一方面，我们希望内聚性保持在较高位置，内聚性高，意味着类中的方法和变量互相依赖。互相结合成一个逻辑整体
10系统
1.将系统的构造与使用分开
2.分解main 3.工厂
使用设计模式抽象复杂逻辑
