命名

  • 避免泛化词: data –> PersonalInfo
  • 带上有效消息:
  • 避免多余的词
  • 避免有歧义的词: fileter –> select, exelude
  • 常量加上单位;
  • 符合语感

  • No surprise!

测试用例命名

  • 测试对象、测试方法、场景描述、预期结果

注释 目的:增加可读性或者信息量

  • 为常量加注释:不是简单的翻译常量的含义,而是需要说清楚为啥取这个值
  • 解释hack (STL swap trick)
  • 提示可能陷阱

  • 不要重复代码的含义

代码问题

  • 本质是对业务的理解和思考、分解的能力;

基本原则

  • 关注 what/why

逻辑

  • 书写规则:
    变量在左,常量在右;
    小于号原则;(符合数轴原则)

小的变量名或者函数(增加可读性)

结构

  • 减少嵌套
  • 异常检查先放在前面;
  • 善用空行:把不同逻辑的代码分开

  • 设计

    • 在抽象层面考虑,是否有其他实现方法;
    • 是否有其他方法,谋定而后动;平时多想一想

    • 多思考,梳理业务逻辑,

    • 设计的本质:控制负责度,控制阅读者、维护者、开发者理解的难度;

    重构

    • 没有验收标准的代码不是好代码
    • 是否能通过测试用例的测试保证回归、自动化;最好通过测试case 通过

    推荐书目:

    编写可读代码的艺术
    code complete