内容摘抄于【代码整洁之道】一书

一、为什么

软件质量与代码整洁度成正比；

延长产品生命周期，可持续化开发与交付；

不整洁的代码，团队的生产力会持续下降；

便于维护，减少技术债；

二、什么算是整洁的代码

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.（不要写重复的代码。）
• 健壮性，可读性强
• 把握时机，敢于无情的重构