内容摘抄于【代码整洁之道】一书
一、为什么
软件质量与代码整洁度成正比；
延长产品生命周期，可持续化开发与交付；
不整洁的代码，团队的生产力会持续下降；
便于维护，减少技术债；
二、什么算是整洁的代码
cleancode.jpg
三、如何写出整洁的代码
3.1 有意义的命名
- 名副其实
- 避免误导
- 做有意义的区分
- 使用可读得出来的名称
- 使用可搜索的名称
- 避免使用编码
- 避免思维映射
- 类名
- 方法名
- 上下文中每个概念对应一个词
- 别用双关语
- 使用解决方案领域名
- 使用源自所涉问题领域的名称
- 添加有意义的语境
- 不要添加没有意义的语境
3.2 函数
- 短小
- 只做一件事（SRP）
- 每个函数一个抽象层级
- Switch语句
- 使用描述性的名称
- 函数参数不要大于3个
- 无副作用 别重复自己
- 分隔指令与询问
3.3 注释
注释不能美化糟糕的代码
- 好的注释： 法律信息 对业务的注释 警示 TODO注释 公共API的注释
- 坏的注释：多余的 误导性的 日志式的 废话注释 位置标记 归属与署名 注释掉的代码 信息过多
3.4 格式
- 垂直格式：垂直方向上的区隔 垂直方向上的靠近 垂直方向上的距离 垂直方向上的顺序
- 水平格式：水平方向上的区隔 水平对其 缩进 空范围
3.5 对象与数据结构
- 数据抽象
- 数据、对象的反对称性
对象把数据隐藏于抽象之后，暴露操作数据的函数。（暴露行为）
数据结构暴露其数据，没有提供有意义的函数。（暴露数据） - 得墨忒耳律——火车失事、混杂、隐藏结构
- 数据传送对象（java中的DTO）
3.6 错误处理
- 使用异常处理函数而非返回码
- 不要产生异常链
- 异常信息要充分有用
- 不要返回null
- 不要传递null
3.7 边界
- 了解使用的第三方程序（问题、未开放的功能等）
- 针对引入的第三方程序，未能满足我们现有需求，可以自定义实现，等待第三方的完善
- 不要深入去修改引入的第三方程序
3.8 逐步改进
- 代码不止能工作，仅仅能工作的代码就像一颗定时炸弹
- 不要做满足于仅仅能让代码工作的程序员
- 整洁的代码不是一次就能写出来的，是一个循序渐进的过程
小结：
- KISS原则：KISS=Keep It Short and Simple.（尽量保持简单。）
- SRP：Single Responsibility Principle.（单一职责原则。）
- DRY原则：Don’t Repeat Yourself.（不要写重复的代码。）
- 健壮性，可读性强
- 把握时机，敢于无情的重构
