【读书笔记】重写可读代码的艺术

一、代码应该易于理解

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

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

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

参考资料

《编写可读代码的艺术》

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。