本文原链接 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_开头
参考资料
- 《编写可读代码的艺术》