本文原链接 https://coderfix.blog.csdn.net/article/details/106239427

一、代码应该易于理解

这里提出一个概念-理解代码时间,我们应该让别人理解代码的时间越短越好。

而不是所用的代码越短越好。

1 变量名称

  • 避免使用temp/size/foo/get/stop这种意义不清晰或者表达意思不多的词汇
  • 循环中如果有意义,避免使用i/j,要用users/numbers这种有业务意义的词
  • 数值带单位,比如秒还是毫秒都是时间,但是加上_ms或者_s就会一下子看出来不会处理出错
  • 作用域很小的时候名称可以是短的
  • 不需要进行首字母缩写

2 命名技巧

  • min和max表示极限
  • first和last表示包含的范围
  • begin和end表示包含/排除范围
  • 布尔值要求定义明确,比如 use_ssl = true
  • 和期望表示一致

3 审美

  • 相似的代码应当看上去相似
  • 必要时使用列对齐,增加空白
  • 用段落隔开增加逻辑

作用

  • 消除大量代码重复
  • 添加新代码更简单
  • 阅读变得更直白

4 注释

  • 注释的目的是帮助读者了解的和作者一样多
  • 写注释之后会提高理解代码的速度,业务简单逻辑复杂的也要写注释
  • 注释加入思考过程,供以后参考
  • 关键字
    • todo 还没处理
    • fixme 已知的无法运行代码
    • hack 粗糙的解决问题方式
    • xxx 危险重要的问题
  • 常量加上注释
  • 标记意料之中的疑问
  • 提前声明代码的问题
  • 全局、总结的注释
  • 声明高层次含义,而不是明显的细节

二、简化循环和逻辑

1 条件语句中的参数顺序

  • 比较的值是不断变化的,比较的表达式的值倾向于常量
  • 优先正逻辑,优先简单逻辑,优先异常
  • 三目运算符只处理最简单的逻辑,默认使用if/else
  • 避免使用do/while
  • 从函数中提前返回return结果,通过提前return减少逻辑嵌套

2 拆分超长的表达式

  • 引入做解释的变量
  • 使用总结变量
  • 德摩根定理,取反之后颠倒逻辑,增加可读性
  • 短路逻辑会增加阅读时间

3 变量的可读性

  • 减少没有价值的临时变量,减少中间结果
  • 缩减作用域
  • 操作变量的地方越多,越难确定他的值

三、重新组织代码

工程学就是大问题拆成小问题再把这些问题的方案放回一起。把这条原则应用于代码会使代码更健壮并且更容易读。

这也就是我们最基本的分而治之以及抽象的思想。

1 积极地发现并抽取不相关的子逻辑

  • 关注更高层次的代码
  • 把一些解决了不相关的子问题的代码,抽出到独立的代码中
  • 子问题更容易被测试
  • 创建大量通用代码/工具类
  • 简化已有接口,按需重塑接口
  • 把一般代码和项目专有代码分开

2 一次只做一件事

应该把代码组织得一次只做一件事情。

  • 整理碎片,切分小任务

2 想法变成代码

  • 清晰的自然语言描述逻辑,注意关键词和短语,写出匹配的代码
  • 如果你不能把问题说明白,那估计是缺少了什么东西或者定义

在这里插入图片描述

泰迪熊太难了~

3 少些代码

最好读的代码就是没有代码。

  • 质疑和拆分需求,学会缩减需求
  • 定期删除没用的代码
  • 重用库
  • 经常熟悉标准库的API,避免重复编写基础代码

三、精选话题

1 测试与可读性

  • 测试具有可读性,测试代码可以当做非正式的文档
  • 对使用者隐去不重要的细节,以便更重要的细节会更突出
  • 让错误信息更具可读性
  • 简化输入值。又简单又能完成工作的测试值更好
  • 给测试命名一般Test_开头

参考资料

  • 《编写可读代码的艺术》