一、代码应该易于理解

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

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

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_开头

参考资料

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

文章来源: coderfix.blog.csdn.net，作者：小雨青年，版权归原作者所有，如需转载，请联系作者。

原文链接：coderfix.blog.csdn.net/article/details/106239427