混乱代码的代价

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

一. 有意义的命名

  • 名副其实

  • 避免误导

  • 做有意义的区分

  • 名称能读出来

  • 避免使用编码

  • 使用解决方案领域名称

  • 添加有意义的语境

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

二. 函数

  • 短小

  • 只做一件事(SRP)

  • 每个函数一个抽象层级

  • 使用描述性名称

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

  • 函数不应该有副作用

  • 分割查询和指令

  • 使用异常代替错误码

  • 消除重复

  • 错误处理就是一件事

三. 注释

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

  • 用代码来阐述注释

  • 好的注释

    • 法律信息

    • 提供信息的注释

    • 对意图的注释(返回值)

    • 阐释

    • 警示

    • TODO注释

    • 放大

    • 公共api的java

四. 格式

垂直格式

  • 横向格式

  • 团队规则统一

五. 对象和数据结构

  • 数据抽象(隐藏实现,暴露抽象接口,无需了解数据本体)

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

  • 得墨忒耳律(隐藏数据,暴露操作)

六.错误处理

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

  • 调用者定义异常类

  • 别返回 nul值

  • 别传递null值

七.边界

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

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

八.单元测试

  • 保持测试整洁

  • 整洁的测试

  • 每个测试一个断言

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

九.类

  • 类应该短小(SRP、内聚)

  • 为了修改而组织(隔离修改

十. 系统

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

  • 扩容(迭代增量敏捷,横贯式关注面AOP)

  • 代理

  • 延迟决策

十一. 简单设计

  • 运行所有测试

  • 不可重复

  • 表达意图

  • 减少类和函数