代码整洁之道
1.代码质量与其整洁度成正比
2.乐嚼是在丹麦最受欢迎的糖果品种之一，它浓郁的甘草味道，完美地弥补了此地潮湿且时常寒冷的天气
4.宏大建筑中最细小的部分，比如关不紧门，有点儿没铺平的地板，甚至凌乱的桌面，都会将整个大局的魅力毁灭殆尽
5.架构只是软件开发用到的借喻之一，主要用在那种等同于建筑师交付毛坯房一般交付初始软件产品的场合
6.即便是在汽车工业里，大量工作也并不在于生产而在于维护或避免维护，对于软件而言，百分之八十或更多的工作量集中在我们其名曰维护的事情上，其实就是修修补补
7.全员生产维护的质量手段在日本出现。
它关注维护甚至关注生产.TPM的主要支柱之一是所谓的5S原则体系
组织，整齐，清洁，标准化，自律
8.无论是架构还是代码都不强求完美，只求竭诚尽力而已。人孰无过，神亦容之
9.宏大建筑中最细小的部分，比如关不紧们，有点儿没铺平的地板，甚至凌乱的桌面，
都会将整个大局的魅力毁灭殆尽
10.习艺之要有二：知和行
1.整洁代码
1.我们永远抛不掉代码，因为代码呈现了需求的细节
2.即便是人类，倾其全部的直觉和创造力，也造不出满足客户模糊感觉的成功系统来
3.糟糕的代码如沼泽
4.只要你干过二三年编程，就有可能曾被某人的糟糕的代码绊倒过，如果你编程不止两三年，也有可能被这种代码拖过后退
5.随着混乱的增加，团队生产力也持续下降，趋向于零。当生产力下降时，管理层就只有一件事可做了，增加更多人手到项目中，期望提升生产力
6.制造混乱无助于赶上期限，混乱只会立刻拖慢你，叫你错过期限
7.编写整洁的代码的程序员就像艺术家，他能用一系列变换把一块白板变作由优雅代码构成的系统
8.当心，语言是冥顽不化的，是程序员让语言变得简单
9.武术家从不认同所谓最好的武术，也不认同所谓的绝招。武术家常常自己创建流派，聚徒而授
10.艺术书并不保证你读过之后能成为艺术家，只能告诉你其他艺术家用过的工具，技术和思维过程
2.有意义的命名
1.一旦发现有更好的名称，就换掉旧的。
2.变量，函数或者类的名称应该已经答复了所有的大问题，它该告诉你，它为什么会存在，它做什么事，应该怎么用，如果名称需要注释来补充，那就不算是名副其实
3.只要改为有意义的名称，代码就会得到相当程度的改进
4.只要简单改一下名称，就能轻易知道发了什么。这就是选用好名称的力量
5.避免误导
6.光是添加数字系列或是废话远远不够，即便这足以让编译器感到满意，如果名称必须相异，那其意思也应该不同才对
7.要区分名称，就要以读者能鉴别不同之处的方式来区别
8.长名称胜于短名称，搜得到的名称胜于其用自造编码代写就的名称
9.应该把类和函数做的足够小，消除成员前缀额需要
10.代码阅读越多，眼中就越没有前缀，最终，前缀变作了不入法眼的废料，变作了旧代码的标志物
11.专业程序员了解，明确才是王道
12.类名和对象名应该是名词或者名词短语
12.方法名应当是动词或动词短语
属性访问器，修改器该根据其值命名，并依javabean标准加上get，set，和is前缀
13.宁可明确，毋办可爱
3.函数
1.函数的第一规则是要短小，第二条规则还要是更短小
2.每个函数都只说了一件事
3.if语句，else语句，while语句其中的代码应该只有一行，该行大抵应该是一个函数调用语句
4。函数应该做一件事，做好这件事
5.我们想要让每个函数后面都跟着位于下一抽象层级的函数
6.长而具有描述性的名称，要比短而令人费解的名称好
7.如果函数看来需要两个，三个，或三个以上，就说明其中一些参数应该封装到类了
8.从参数创建对象，从而减少参数数量
9.函数要么做什么事，要么回答什么事，但二者不可兼得。函数应该修改某对象的状态，或者返回该对象的有关信息，两样都干会导致混乱
10.真正解决方案是把指令和询问分割开来，防止混淆
11.如果使用异常替代返回错误码，错误处理代码就能从主路径代码分离出来
12.try/catch代码丑陋不堪，他们搞乱了代码结构，把错误处理与正常流程混为一谈，最好把try/catch代码体的主体部分抽离出来，另外形成函数
13.函数处理一件事，错误处理一件事
14.重复可能是软件中一切邪恶的根源
15.函数是语言的动词，类是语言的名词
4.注释
1.注释的恰当用法是弥补我们在用代表示意图时遭遇的失败
2.TODO注释解释了为什么函数的实现部门无所作为，将来应该怎么样
3.注释以及描述的代码之间的联系应该显而易见
5.格式
1.在封包声明，导入声明，和每个函数之间，都有空白行隔开，
这条极其简单的规则极大影响到代码的视觉外观，每个空白行都是一条线索，标识出新的独立概念
2.靠近的代码行则暗示了他们之间的关系
3.相关函数，调用者应该尽量可能放在被调用者上面
4.相关概念的代码应该放在一起
5.赋值语句有两个确定的而重要的要素，左边和右边，空格符加强了分割效果
6.函数括号中的参数一一隔开，强调逗号，标识参数是互相分离的
7.乘法之间没有空格，因为优先级较高，加减法之间用空格，优先级较低
6.对象和数据结构
1.过程式代码便于在不改动既有数据结构的前提下添加新函数，
面向对象代码便于在不改动既有函数的前提下添加新类
2. 类C的方法f只应调用以下对象的方法：
(1)C；
(2)由f创建的对象；
(3)作为参数传递给f的对象；
(4)由C的实体变量持有的对象；
方法不应调用由任何函数返回的对象的方法，换句话说，只和朋友说话，不和陌生人说话。以下就是违反该法则的一段代码：
final String outputDir=ctxt.getOptions().getScratchDir().getAbsolutePath();
当然，迪米特法则的前提是对象，如果是数据结构，没有什么行为，则他们自然会暴露其内部数据结构，迪米特法则也失效了。
如果数据结构只简单的拥有公共变量而没有函数，对象拥有私有变量和公共函数，这个问题就不会混淆。
7.错误处理
1.异常太过复杂，通过打包调用API，确保它返回通用的异常类型
1.1
1.2
1.3
2.错误处理很重要，但如果它搞乱了代码逻辑，就是错误的做法
3.try代码块就像事务，catch代码块将程序维持在一种持续状态
4.返回null值，基本上就是在给自己增加工作量，也在给调用添堵，只要有一处没检查异常，应用程序就会失控
5.如果你打算在方法返回null值，不如抛出异常，或者返回特例对象。
如果你在调用某个第三方API中可能返回null值的方法，可以考虑用新方法打包这个方法，在新方法中抛出异常或返回特例对象。
6。你在编码的时候，就会时刻时时记住参数列表中的null值意味着出问题了，从而大量避免这种无心之失
8.边界
9.单元测试
1.TDD三定律
测试驱动开发（Test Driven Development）
1、在编写不能通过的单元测试前,不可编写生产代码。
2、只可编写刚好无法通过的单元测试,不能编译也算不通过。
3、只可编写刚好足以通过当前失败测试的生产代码。
总的来说就是先写测试再写生产代码，写一个测试就应该立即写它的实现代码。
测试代码和生产代码一样重要，它需要被思考，被设计和被照料,它该像生产代码一样保持整洁
2.整洁的测试的三要素，可读性，可读性，可读性。
明确，简洁，还有足够的表达力
3.每个测试都清晰的拆分为三个环节，第一个环节构造测试数据，第二个环节操作测试数据，第三部分检验操作数据是否是期望的结果
4.每一个测试一个概念，每个测试中只测试一个概念
5.F.I.R.S.T
整洁的代码应该遵循5条原则
快速，测试运行缓慢的话，你就不会想要频繁的运行它，如果你不频繁运行测试，就不能尽早发现问题，也无法轻易修正，从而不能轻而易举的清理代码
独立，测试应该相互独立
可重复
自足验证：测试应该有布尔值的输出，无论通过还是失败，你不应该查看日志文件来确认测试是否通过
10.类
1.遵循标准的java约定，类应该从一组变量列表开始，如果有公共静态常量，应该先出现，然后是私有静态变量，以及私有实体变量，很少会有公共变量
公共函数应跟在变量列表之后
2.类的第一条规则是类应该短小
3.单一权责原则认为，类或模块应有且只有一条加以修改的地方
4.系统应该由许多短小的类而不是少量巨大的类组成，每个小类封装一个权责，只有一个修改的原因，并与少数其他类一起协同达成期望的系统行为
5.类应该只有少量的实体变量，类中的每个方法都应该操作一个或多个这种变量，方法操作的变量越多，就越黏聚到类上，如果一个类中的每个变量都被每个方法所使用，则类具有最大的内聚性
6.内聚性高，意味着类中的方法和变量互相依赖，互相结合成一个逻辑整体
7.一个类要从大类中挣扎出来，你应该尝试将这些变量或方法分拆到两个或多个类中，让新的类更为内聚
8.看一个有许多变量的大函数，你想把该函数中的某一小部分拆解成单独的函数
9.开放-闭合原则（OCP） ：类应该对扩展开放，对修改封闭
10.我们通过扩展系统而非修改现有代码来添加新特性
11.系统
1。
这就是所谓的延迟初始化/赋值，也有一些好处，在真正用到对象之前，无需操心这种架空构造，启始时间也会更短，而且还能保证永远不会返回null值
2.软件系统应将启始过程和启始过程之后的运行时逻辑分离开，在启始过程中构建应用对象，也会存在互相缠结的依赖关系
3.一开始就做对系统纯属神话，反之，我们应该只去实现今天的用户故事，然后重构，明天再扩展系统，实现新的用户故事，这就是迭代和增量敏捷的精髓所在
12.迭进
1.紧耦合的代码难以编写测试。同样编写测试越多，就会越遵循DIP之类的原则，使用依赖注入，接口和抽象等工具尽可能减少耦合。如此一来设计就会有长足进步。遵循有关编写测试并持续运行测试的、明确的规则，系统就会更贴近OO低耦合度、高内聚的目标。
2.应用简单设计后三条规则的地方，消除重复，保证表达力，尽可能减少类和方法的数量
3.重复是拥有良好设计系统的大敌，它代码额外的工作，额外的风险和额外且不必要的复杂度
4.做一点共性抽取
5.软件项目的主要成本在于长期维护，代码应该清晰地表达其作者的意图，作者把代码写的越清晰，其他人花在理解代码上的时间也就越少，从而减少缺陷，缩减维护成本
14.逐步改进
来源：https://www.cnblogs.com/sharpest/p/8693609.html