混乱代码的代价

难以维护，降低生产力，增加系统错误风险，最后导致无法运行。

一. 有意义的命名

• 名副其实

• 避免误导

• 做有意义的区分

• 名称能读出来

• 避免使用编码

• 使用解决方案领域名称

• 添加有意义的语境

• 描述技巧和共有文化背景

二. 函数

• 短小

• 只做一件事（SRP）

• 每个函数一个抽象层级

• 使用描述性名称

• 函数参数尽量少和使用动词与关键字

• 函数不应该有副作用

• 分割查询和指令

• 使用异常代替错误码

• 消除重复

• 错误处理就是一件事

三. 注释

•  注释不能美化糟糕的代码

• 用代码来阐述注释

• 好的注释

  • 法律信息

  • 提供信息的注释

  • 对意图的注释（返回值）

  • 阐释

  • 警示

  • TODO注释

  • 放大

  • 公共api的java       

四. 格式

垂直格式

• 横向格式

• 团队规则统一

五. 对象和数据结构

• 数据抽象（隐藏实现，暴露抽象接口，无需了解数据本体）

• 数据、对象的反对称性（过程式编程还是多态式实现） 

• 得墨忒耳律（隐藏数据，暴露操作）

六.错误处理

• 使用异常而非使用错误码

• 调用者定义异常类

• 别返回 nul值

• 别传递null值

七.边界

• 封装隔离来自第三方的api

• 使用适配器模式隔离尚不存在的api

八.单元测试

• 保持测试整洁

• 整洁的测试

• 每个测试一个断言

• 快速、独立、可重复、及时

九.类

• 类应该短小（SRP、内聚）

• 为了修改而组织（隔离修改）

十. 系统

• 系统的构造和使用分开（工厂、依赖注入）

• 扩容（迭代增量敏捷，横贯式关注面AOP）

• 代理

• 延迟决策

十一. 简单设计

• 运行所有测试

• 不可重复

• 表达意图

• 减少类和函数