背景介绍
最近在团队工作中花了不少心思主导建设了测试平台,前期的建设思路是能用就行,随着建设的深入,逐渐需要学习下代码架构设计方面的内容了。于是参加了公司组织的代码重构与模式的培训,通过培训,感觉收获颇丰,故有此文,上一篇是从代码设计原则角度出发内容的总结,本篇是从重构的技术细节出发,进行的总结。
从名字开始规范
避免使用泛泛的名字
例如temp,foo,i,var等,尽量替换成含义相对明确的变
例如下面这段代码,你能想到上面retval是什么吗?是:return value
如果替换成这样的,阅读起来就更加清晰一些
在循环中,i,可以加上循环的前缀来命名
for (int i = 0; i < clubs.size(); i++)
for (int j = 0; j < clubs[i].members.size(); j++)
for (int k = 0; k < users.size(); k++)
if (clubs[i].members[k] == users[j])
cout << "user[" << j << "] is in club[" << i << "]" << endl;
if (clubs[ci].members[ui] == users[mi]) // Bug
if (clubs[ci].members[mi] == users[ui]) // Ok
为名字附带更多的信息
例如:时间的命名,带上单位;加上形容词等方式。
Start(int delay) #这个延时是秒还是毫秒?
Start(int delay_ms) #毫秒延时,很清晰
避免让人误解的名称
- 例如:Filter的含义。传参:addr="郑州",是要郑州的还是不要郑州的?
- 例如:start-end,可以换成first,last,可以清晰边界
- 例如给布尔值命名:
- bool read_password = True 这种含义不清,可以加上is can has should等
- 避免使用否定词:例如bool disable_ssl =False
提升代码的可读性
按照杂志的思想组织,而不是报纸的思路组织。
杂志有目录,整体有结构,从哪里开始都可以
提取公共部分
例如下面的修改:
修改前:
修改后:
用函数来整理不规则的代码
修改前:
修改后
把声明按块组织
修改前
修改后:分块添加注释
使用自描述代码替代大量注释
修改前
修改后
关于注释
- 好代码 > 坏代码 + 好注释
- 避免喃喃式注释。
- 注释尽量写背景信息,也就是为什么要有这个。
什么情况下写注释
给常量添加注释
EG:NUM_THREADS = 8 # 只要 >= 2 * num_processors, 就足够了.
给意料之中的提问加注释
// 只有与空vector交换才能真正回收内存
公布可能的陷阱
让注释保持紧凑
可以适当的使用一些符号,不必是纯文字表达。
修改前
修改后
正如下图
优化 条件判断与循环
先处理正向逻辑
反例:
调整为:
只在简单的条件下使用三目运算符
避免使用do……while
通过提前返回减少嵌套
例如:
修改为
较少循环内嵌套
拆分复杂表达式
用解释变量简化表达式
把超长表达式拆分成更容易理解的小块
不要滥用短路逻辑
换个表达的角度
例如:判断重叠的逻辑
正向逻辑的表达:太复杂
反向分析:
通过查表简化逻辑
如何写一个好的Unit Test
提取为统一函数
修改前:
修改后:
写在最后
这部分总结是将代码重构细节操作的角度进行了总结,里面有不少例子,看了就能懂,拿来就能用,对于我这种经验不足的人来说,刚刚好。因此这次培训也算是打开了我进行代码重构、代码架构设计的一扇窗,希望之后能继续深入学习、实践!