背景介绍
最近在团队工作中花了不少心思主导建设了测试平台,前期的建设思路是能用就行,随着建设的深入,逐渐需要学习下代码架构设计方面的内容了。于是参加了公司组织的代码重构与模式的培训,通过培训,感觉收获颇丰,故有此文,上一篇是从代码设计原则角度出发内容的总结,本篇是从重构的技术细节出发,进行的总结。
从名字开始规范
避免使用泛泛的名字
例如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
提取为统一函数
修改前:

修改后:

写在最后
这部分总结是将代码重构细节操作的角度进行了总结,里面有不少例子,看了就能懂,拿来就能用,对于我这种经验不足的人来说,刚刚好。因此这次培训也算是打开了我进行代码重构、代码架构设计的一扇窗,希望之后能继续深入学习、实践!
本文分享了作者在主导测试平台建设过程中,通过参加代码重构培训所学到的命名规范、提升代码可读性以及优化条件判断等方面的技巧,旨在帮助读者理解和实践代码重构,提高代码质量。

373

被折叠的 条评论
为什么被折叠?



