混乱的代价

  • 稍后等于永不 勒布朗法则
  • 简单代码规则
    • 能通过所有的测试
    • 没有重复的代码
    • 体现系统中的全部设计理念
    • 包括尽量少的实体，比如类，方法，函数等
  • 更改的原则
    • 更改一个变量名
    • 拆分一个过长的函数
    • 消除重复的代码
    • 清理嵌套的if语句

函数

  • 函数要么做事情，要么回答什么事
    • 要么do什么操作
    • 要么返回值
    • 这种指定需要分割开
  • 使用异常替代返回的错误码
    • 多使用抛出异常
  • 抽离Try/catch 代码块
  • 错误处理只做一件事
  • 如果错误基类暂时不满足需求，那需要生成新的类来处理(类派生)
  • 不要重复自己

注释

  • 注释不能美化代码，要花更多的心思减少注释
  • 好注释有哪些
    • 法律信息
    • 提供信息的注释
    • 对意图的解释
    • 阐释
    • 警示
    • TODO注释
    • 放大
    • 公共API中的Doc
  • 坏注释
    • 能用函数或者变量的时候就别用注释

错误处理

  • 如果错误处理搞乱了代码的逻辑，那就是错误的做法
  • 使用异常而非返回码
  • 先写try-catch-finnaly语句
    • 将代码的业务 错误 返回 从代码层面分割开
  • 使用不可控异常 python本支持这种
  • 给出异常的发生环境说明
    • 错误处理必须带上环境变量和正常的调用堆栈踪迹(stack-track)将给日志程序
  • 根据调用者需要定义异常类
    • 将某一类的错误进行代码，这样可以将同一类的错误包裹在一起
def open_port(port):
    try:
        port.open()
    except DeviceResponseException
        raise PortDeviceError
    except ATM1212UnlockedException
        raise PortDeviceError
    except GMXError
        raise PortDeviceError
        #将来源的不同的错误分类统一在一个外部的错误出口这里
  • 定义常规的流程
  • 别返回null值 这个不适合python这类语言
  • 别传递null值 如果参数为null值，那就是出问题了

整洁的代码是可读的，也要坚固

类

  • 类应该短小
  • 单一权责原则 - 只有一个修改的原因
  • 内聚
    • 类应该只有少量的实体变量
    • 如果一个类中的每个变量都被每个方法所使用，则该类具有最大的内聚性
  • 保持聚性就会得到许多短小的类