如何重构“箭头型”代码

文章有点长，我在文章最后会给出相关的思考和总结陈词，你可以跳到结尾。

所谓箭头型代码，基本上来说就是下面这个图片所示的情况。

那么，这样“箭头型”的代码有什么问题呢？看上去也挺好看的，有对称美。但是……

关于箭头型代码的问题有如下几个：

1）我的显示器不够宽，箭头型代码缩进太狠了，需要我来回拉水平滚动条，这让我在读代码的时候，相当的不舒服。

2）除了宽度外还有长度，有的代码的<code>if-else</code>里的<code>if-else</code>里的<code>if-else</code>的代码太多，读到中间你都不知道中间的代码是经过了什么样的层层检查才来到这里的。

总而言之，“箭头型代码”如果嵌套太多，代码太长的话，会相当容易让维护代码的人（包括自己）迷失在代码中，因为看到最内层的代码时，你已经不知道前面的那一层一层的条件判断是什么样的，代码是怎么运行到这里的，所以，箭头型代码是非常难以维护和Debug的。

OK，我们先来看一下微博上的那个示例，代码量如果再大一点，嵌套再多一点，你很容易会在条件中迷失掉（下面这个示例只是那个“大箭头”下的一个小箭头）

<code>FOREACH(Ptr<WfExpression>, argument, node->arguments) {</code>

<code></code><code>int</code> <code>index = manager->expressionResolvings.Keys().IndexOf(argument.Obj());</code>

<code></code><code>if</code> <code>(index != -1) {</code>

<code></code><code>auto</code> <code>type = manager->expressionResolvings.Values()[index].type;</code>

<code></code><code>if</code> <code>(! types.Contains(type.Obj())) {</code>

<code></code><code>types.Add(type.Obj());</code>

<code></code><code>if</code> <code>(</code><code>auto</code> <code>group = type->GetTypeDescriptor()->GetMethodGroupByName(L</code><code>"CastResult"</code><code>,</code><code>true</code><code>)) {</code>

<code></code><code>int</code> <code>count = group->GetMethodCount();</code>

<code></code><code>for</code> <code>(</code><code>int</code> <code>i = 0; i < count; i++) {</code><code>auto</code> <code>method = group->GetMethod(i);</code>

<code></code><code>if</code> <code>(method->IsStatic()) {</code>

<code></code><code>if</code> <code>(method->GetParameterCount() == 1 &&</code>

<code></code><code>method->GetParameter(0)->GetType()->GetTypeDescriptor() == description::GetTypeDescriptor<DescriptableObject>() &&</code>

<code></code><code>method->GetReturn()->GetTypeDescriptor() != description::GetTypeDescriptor<</code><code>void</code><code>>() ) {</code>

<code></code><code>symbol->typeInfo = CopyTypeInfo(method->GetReturn());</code>

<code></code><code>break</code><code>;</code>

上面这段代码，可以把条件反过来写，然后就可以把箭头型的代码解掉了，重构的代码如下所示：

<code></code><code>if</code> <code>(index == -1)</code><code>continue</code><code>;</code>

<code></code><code>if</code> <code>( types.Contains(type.Obj()))</code><code>continue</code><code>;</code>

<code></code><code>auto</code> <code>group = type->GetTypeDescriptor()->GetMethodGroupByName(L</code><code>"CastResult"</code><code>,</code><code>true</code><code>);</code>

<code></code><code>if</code> <code>( ! group )</code><code>continue</code><code>;</code>

<code></code><code>if</code> <code>(! method->IsStatic())</code><code>continue</code><code>;</code>

<code></code><code>if</code> <code>( method->GetParameterCount() == 1 &&</code>

这种代码的重构方式叫 Guard Clauses

这里的思路其实就是，让出错的代码先返回，前面把所有的错误判断全判断掉，然后就剩下的就是正常的代码了。

1.近期整理了20G资源，包含产品/运营/测试/程序员/市场等，互联网从业者【工作必备干货技巧、行业专业书籍、面试真题宝典等】，获取方式：

微信扫码关注公众号“非典型互联网”，转发文章到朋友圈，截图发至公众号后台，即可获取干货资源链接；

2.互联网人交流群：

关注公众号“非典型互联网”，在公众号后台回复“入群”，人脉共享，一起交流；

微博上有些人说，continue 语句破坏了阅读代码的通畅，我觉得他们一定没有好好读这里面的代码，其实，我们可以看到，所有的 if 语句都是在判断是否出错的情况，所以，在维护代码的时候，你可以完全不理会这些 if 语句，因为都是出错处理的，而剩下的代码都是正常的功能代码，反而更容易阅读了。当然，一定有不是上面代码里的这种情况，那么，不用continue ，我们还能不能重构呢？

当然可以，抽成函数：

<code>bool</code> <code>CopyMethodTypeInfo(</code><code>auto</code> <code>&method,</code><code>auto</code> <code>&group,</code><code>auto</code> <code>&symbol)</code>

<code></code><code>if</code> <code>(! method->IsStatic()) {</code>

<code></code><code>return</code> <code>true</code><code>;</code>

<code></code><code>return</code> <code>false</code><code>;</code>

<code>void</code> <code>ExpressionResolvings(</code><code>auto</code> <code>&manager,</code><code>auto</code> <code>&argument,</code><code>auto</code> <code>&symbol)</code>

<code></code><code>if</code> <code>(index == -1)</code><code>return</code><code>;</code>

<code></code><code>if</code> <code>( types.Contains(type.Obj()))</code><code>return</code><code>;</code>

<code></code><code>if</code> <code>( ! group )</code><code>return</code><code>;</code>

<code></code><code>if</code> <code>( ! CopyMethodTypeInfo(method, group, symbol) )</code><code>break</code><code>;</code>

<code></code><code>ExpressionResolvings(manager, arguments, symbol)</code>

你发出现，抽成函数后，代码比之前变得更容易读和更容易维护了。不是吗？

有人说：“如果代码不共享，就不要抽取成函数！”，持有这个观点的人太死读书了。函数是代码的封装或是抽象，并不一定用来作代码共享使用，函数用于屏蔽细节，让其它代码耦合于接口而不是细节实现，这会让我们的代码更为简单，简单的东西都能让人易读也易维护。这才是函数的作用。

微博上还有人问，原来的代码如果在各个 if 语句后还有要执行的代码，那么应该如何重构。比如下面这样的代码。

原版

<code></code><code>do_before_cond1()</code>

<code></code><code>do_before_cond2();</code>

<code></code><code>do_before_cond3();</code>

<code></code><code>do_something();</code>

<code></code><code>do_after_cond3();</code>

<code></code><code>do_after_cond2();</code>

<code></code><code>do_after_cond1();</code>

上面这段代码中的那些 <code>do_after_condX()</code> 是无论条件成功与否都要执行的。所以，我们拉平后的代码如下所示：

重构第一版

<code></code><code>do_before_cond1();</code>

<code></code><code>continue</code>

<code></code><code>continue</code><code>;</code>

你会发现，上面的 <code>do_after_condX</code> 出现了两份。如果 if 语句块中的代码改变了某些<code>do_after_condX</code>依赖的状态，那么这是最终版本。

但是，如果它们之前没有依赖关系的话，根据 DRY 原则，我们就可以只保留一份，那么直接掉到 if 条件前就好了，如下所示：

重构第二版

<code></code><code>if</code> <code>( !cond1 )</code><code>continue</code><code>;</code>

<code></code><code>if</code> <code>( !cond2 )</code><code>continue</code><code>;</code>

<code></code><code>if</code> <code>( !cond3 )</code><code>continue</code><code>;</code>

此时，你会说，我靠，居然，改变了执行的顺序，把条件放到 <code>do_after_condX()</code> 后面去了。这会不会有问题啊？

其实，你再分析一下之前的代码，你会发现，本来，cond1 是判断 do_before_cond1() 是否出错的，如果有成功了，才会往下执行。而 do_after_cond1() 是无论如何都要执行的。从逻辑上来说，do_after_cond1()其实和do_before_cond1()的执行结果无关，而 cond1 却和是否去执行 do_before_cond2() 相关了。如果我把断行变成下面这样，反而代码逻辑更清楚了。

重构第三版

<code></code><code>if</code> <code>( !cond1 )</code><code>continue</code><code>;</code><code>// <-- cond1 成了是否做第二个语句块的条件</code>

<code></code><code>if</code> <code>( !cond2 )</code><code>continue</code><code>;</code><code>// <-- cond2 成了是否做第三个语句块的条件</code>

<code></code><code>if</code> <code>( !cond3 )</code><code>continue</code><code>;</code><code>//<-- cond3 成了是否做第四个语句块的条件</code>

于是乎，在未来维护代码的时候，维护人一眼看上去就明白，代码在什么时候会执行到哪里。这个时候，你会发现，把这些语句块抽成函数，代码会干净的更多，再重构一版：

重构第四版

<code></code><code>return</code> <code>cond3;</code>

<code></code><code>return</code> <code>cond2;</code>

<code></code><code>return</code> <code>cond1;</code>

<code>// for-loop 你可以重构成这样</code>

<code></code><code>if</code> <code>(cond) do_something();</code>

<code>// for-loop 也可以重构成这样</code>

<code></code><code>if</code> <code>( ! do_func1() )</code><code>continue</code><code>;</code>

<code></code><code>if</code> <code>( ! do_func2() )</code><code>continue</code><code>;</code>

<code></code><code>if</code> <code>( ! do_func3() )</code><code>continue</code><code>;</code>

上面，我给出了两个版本的for-loop，你喜欢哪个？我喜欢第二个。这个时候，因为for-loop里的代码非常简单，就算你不喜欢 continue ，这样的代码阅读成本已经很低了。

接下来，我们再来看另一个示例。下面的代码的伪造了一个场景——把两个人拉到一个一对一的聊天室中，因为要检查双方的状态，所以，代码可能会写成了“箭头型”。

<code>int</code> <code>ConnectPeer2Peer(Conn *pA, Conn* pB, Manager *manager)</code>

<code></code><code>if</code> <code>( pA->isConnected() ) {</code>

<code></code><code>manager->Prepare(pA);</code>

<code></code><code>if</code> <code>( pB->isConnected() ) {</code>

<code></code><code>manager->Prepare(pB);</code>

<code></code><code>if</code> <code>( manager->ConnectTogther(pA, pB) ) {</code>

<code></code><code>pA->Write(</code><code>"connected"</code><code>);</code>

<code></code><code>pB->Write(</code><code>"connected"</code><code>);</code>

<code></code><code>return</code> <code>S_OK;</code>

<code></code><code>return</code> <code>S_ERROR;</code>

<code></code><code>pA->Write(</code><code>"Peer is not Ready, waiting..."</code><code>);</code>

<code></code><code>return</code> <code>S_RETRY;</code>

<code></code><code>manager->Prepare();</code>

<code></code><code>pB->Write(</code><code>"Peer is not Ready, waiting..."</code><code>);</code>

<code></code><code>pA->Close();</code>

<code></code><code>pB->Close();</code>

<code></code><code>//Shouldn't be here!</code>

重构上面的代码，我们可以先分析一下上面的代码，说明了，上面的代码就是对 PeerA 和 PeerB 的两个状态 “连上”， “未连上” 做组合 “状态” （注：实际中的状态应该比这个还要复杂，可能还会有“断开”、“错误”……等等状态），于是，我们可以把代码写成下面这样，合并上面的嵌套条件，对于每一种组合都做出判断。这样一来，逻辑就会非常的干净和清楚。

<code></code><code>if</code> <code>(pA->isConnected() && ! pB->isConnected() ) {</code>

<code></code><code>pA->Write(</code><code>"Peer is not Ready, waiting"</code><code>);</code>

<code></code><code>}</code><code>else</code> <code>if</code> <code>( !pA->isConnected() && pB->isConnected() ) {</code>

<code></code><code>pB->Write(</code><code>"Peer is not Ready, waiting"</code><code>);</code>

<code></code><code>}</code><code>else</code> <code>if</code> <code>(pA->isConnected() && pB->isConnected() ) {</code>

<code></code><code>if</code> <code>( ! manager->ConnectTogther(pA, pB) ) {</code>

对于 <code>if-else</code> 语句来说，一般来说，就是检查两件事：错误和状态。

对于检查错误来说，使用 Guard Clauses 会是一种标准解，但我们还需要注意下面几件事：

1）当然，出现错误的时候，还会出现需要释放资源的情况。你可以使用 <code>goto fail;</code> 这样的方式，但是最优雅的方式应该是C++面向对象式的 RAII 方式。

2）以错误码返回是一种比较简单的方式，这种方式有很一些问题，比如，如果错误码太多，判断出错的代码会非常复杂，另外，正常的代码和错误的代码会混在一起，影响可读性。所以，在更为高组的语言中，使用 <code>try-catch</code> 异常捕捉的方式，会让代码更为易读一些。

对于检查状态来说，实际中一定有更为复杂的情况，比如下面几种情况：

1）像TCP协议中的两端的状态变化。

2）像shell各个命令的命令选项的各种组合。

3）像游戏中的状态变化（一棵非常复杂的状态树）。

4）像语法分析那样的状态变化。

对于这些复杂的状态变化，其本上来说，你需要先定义一个状态机，或是一个子状态的组合状态的查询表，或是一个状态查询分析树。

写代码时，代码的运行中的控制状态或业务状态是会让你的代码流程变得混乱的一个重要原因，重构“箭头型”代码的一个很重要的工作就是重新梳理和描述这些状态的变迁关系。

好了，下面总结一下，把“箭头型”代码重构掉的几个手段如下：

1）使用 Guard Clauses 。尽可能的让出错的先返回，这样后面就会得到干净的代码。

2）把条件中的语句块抽取成函数。有人说：“如果代码不共享，就不要抽取成函数！”，持有这个观点的人太死读书了。函数是代码的封装或是抽象，并不一定用来作代码共享使用，函数用于屏蔽细节，让其它代码耦合于接口而不是细节实现，这会让我们的代码更为简单，简单的东西都能让人易读也易维护，写出让人易读易维护的代码才是重构代码的初衷！

4）对于多个状态的判断和组合，如果复杂了，可以使用“组合状态表”，或是状态机加Observer的状态订阅的设计模式。这样的代码即解了耦，也干净简单，同样有很强的扩展性。

5）重构“箭头型”代码其实是在帮你重新梳理所有的代码和逻辑，这个过程非常值得为之付出。重新整思路去想尽一切办法简化代码的过程本身就可以让人成长。

作者：陈皓，博客地址：https://coolshell.cn/articles/18190.html

如何重构“箭头型”代码

继续阅读

Oracle索引内部结构研究

MySQL和Lucene索引对比分析1. MySQL索引实现2. Lucene索引实现3. MySQL与Lucence对比参考：

一文搞定 MySQL 索引

MySQL（第五篇）—数据的完整性约束（2）（索引、引用完整性）数据的完整性约束（2）三、索引四、引用完整性

【MySQL索引】MySQL索引分类，90%的开发都不知道一、根据底层数据结构划分二、根据索引字段个数划分三、根据是否是在主键上建立的索引进行划分四、根据数据与索引的存储关联性划分五、其他分类六、总结

JS--------for循环删除数组元素

Python中字符串常见操作总结

Lucence的基本原理

sql执行计划 explain 以及结合索引优化sql

MySQL - order by排序优化

2021-08-08 mysql索引

SQLServer 提升查询速度

详解SQL中几种常用的表连接方式

oracle 中不使用已有的索引解决办法

对first_name创建唯一索引uniq_idx_firstname问题描述Sql语句

记一次因MySQL编码问题导致的慢查询排查