如何重构“箭头型”代码

本文主要起因是,一次在微博上和朋友关于嵌套好几层的if-else语句的代码重构的讨论(微博原文),在微博上大家有各式各样的问题和想法。按道理来说这些都是编程的基本功,似乎不太值得写一篇文章,不过我觉得很多东西可以从一个简单的东西出发,到达本质,所以,我觉得有必要在这里写一篇的文章。不一定全对,只希望得到更多的讨论,因为有了更深入的讨论才能进步。

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

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

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

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

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

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

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

微博上的案例 与 Guard Clauses

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
FOREACH(Ptr<WfExpression>, argument, node->arguments) {
    int index = manager->expressionResolvings.Keys().IndexOf(argument.Obj());
    if (index != -1) {
        auto type = manager->expressionResolvings.Values()[index].type;
        if (! types.Contains(type.Obj())) {
            types.Add(type.Obj());
            if (auto group = type->GetTypeDescriptor()->GetMethodGroupByName(L"CastResult", true)) {
                int count = group->GetMethodCount();
                for (int i = 0; i < count; i++) { auto method = group->GetMethod(i);
                    if (method->IsStatic()) {
                        if (method->GetParameterCount() == 1 &&
                            method->GetParameter(0)->GetType()->GetTypeDescriptor() == description::GetTypeDescriptor<DescriptableObject>() &&
                            method->GetReturn()->GetTypeDescriptor() != description::GetTypeDescriptor<void>() ) {
                            symbol->typeInfo = CopyTypeInfo(method->GetReturn());
                            break;
                        }
                    }
                }
            }
        }
    }
}

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
FOREACH(Ptr<WfExpression>, argument, node->arguments) {
    int index = manager->expressionResolvings.Keys().IndexOf(argument.Obj());
    if (index == -1)  continue;
     
    auto type = manager->expressionResolvings.Values()[index].type;
    if ( types.Contains(type.Obj()))  continue;
     
    types.Add(type.Obj());
    auto group = type->GetTypeDescriptor()->GetMethodGroupByName(L"CastResult", true);
    if  ( ! group ) continue;
  
    int count = group->GetMethodCount();
    for (int i = 0; i < count; i++) { auto method = group->GetMethod(i);
        if (! method->IsStatic()) continue;
        
        if ( method->GetParameterCount() == 1 &&
               method->GetParameter(0)->GetType()->GetTypeDescriptor() == description::GetTypeDescriptor<DescriptableObject>() &&
               method->GetReturn()->GetTypeDescriptor() != description::GetTypeDescriptor<void>() ) {
            symbol->typeInfo = CopyTypeInfo(method->GetReturn());
            break;
        }
    }
}

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

  • Martin Fowler 的 Refactoring 的网站上有相应的说明《Replace Nested Conditional with Guard Clauses》。
  • Coding Horror 上也有一篇文章讲了这种重构的方式 —— 《Flattening Arrow Code》
  • StackOverflow 上也有相关的问题说了这种方式 —— 《Refactor nested IF statement for clarity》

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

抽取成函数

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

当然可以,抽成函数:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
bool CopyMethodTypeInfo(auto &method, auto &group, auto &symbol)
{
    if (! method->IsStatic()) {
        return true;
    }
    if ( method->GetParameterCount() == 1 &&
           method->GetParameter(0)->GetType()->GetTypeDescriptor() == description::GetTypeDescriptor<DescriptableObject>() &&
           method->GetReturn()->GetTypeDescriptor() != description::GetTypeDescriptor<void>() ) {
        symbol->typeInfo = CopyTypeInfo(method->GetReturn());
        return false;
    }
    return true;
}
void ExpressionResolvings(auto &manager, auto &argument, auto &symbol)
{
    int index = manager->expressionResolvings.Keys().IndexOf(argument.Obj());
    if (index == -1) return;
     
    auto type = manager->expressionResolvings.Values()[index].type;
    if ( types.Contains(type.Obj())) return;
    types.Add(type.Obj());
    auto group = type->GetTypeDescriptor()->GetMethodGroupByName(L"CastResult", true);
    if  ( ! group ) return;
    int count = group->GetMethodCount();
    for (int i = 0; i < count; i++) { auto method = group->GetMethod(i);
        if ( ! CopyMethodTypeInfo(method, group, symbol) ) break;
    }
}
...
...
FOREACH(Ptr<WfExpression>, argument, node->arguments) {
    ExpressionResolvings(manager, arguments, symbol)
}
...
...

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

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

嵌套的 if 外的代码

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

原版
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
for(....) {
    do_before_cond1()
    if (cond1) {
        do_before_cond2();
        if (cond2) {
            do_before_cond3();
            if (cond3) {
                do_something();
            }
            do_after_cond3();
        }
        do_after_cond2();
    }
    do_after_cond1();
}

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

重构第一版
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
for(....) {
    do_before_cond1();
    if ( !cond1 ) {
        do_after_cond1();
        continue
    }
    do_after_cond1();
    do_before_cond2();
    if ( !cond2 ) {
        do_after_cond2();
        continue;
    }
    do_after_cond2();
    do_before_cond3();
    if ( !cond3 ) {
        do_after_cond3();
        continue;
    }
    do_after_cond3();
    do_something(); 
}

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

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

重构第二版
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
for(....) {
    do_before_cond1();
    do_after_cond1();
    if ( !cond1 ) continue;
  
    do_before_cond2();
    do_after_cond2();
    if ( !cond2 ) continue;
    do_before_cond3();
    do_after_cond3();
    if ( !cond3 ) continue;
    do_something(); 
}

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

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

重构第三版
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
for(....) {
    do_before_cond1();
    do_after_cond1();
    if ( !cond1 ) continue// <-- cond1 成了是否做第二个语句块的条件
    do_before_cond2();
    do_after_cond2();
    if ( !cond2 ) continue; // <-- cond2 成了是否做第三个语句块的条件
    do_before_cond3();
    do_after_cond3();
    if ( !cond3 ) continue; //<-- cond3 成了是否做第四个语句块的条件
    do_something();
  
}

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

重构第四版
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
bool do_func3() {
   do_before_cond2();
   do_after_cond2();
   return cond3;
}
bool do_func2() {
   do_before_cond2();
   do_after_cond2();
   return cond2;
}
bool do_func1() {
   do_before_cond1();
   do_after_cond1();
   return cond1;
}
// for-loop 你可以重构成这样
for (...) {
    bool cond = do_func1();
    if (cond) cond = do_func2();
    if (cond) cond = do_func3();
    if (cond) do_something();
}
// for-loop 也可以重构成这样
for (...) {
    if ( ! do_func1() ) continue;
    if ( ! do_func2() ) continue;
    if ( ! do_func3() ) continue;
    do_something();
}

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

状态检查嵌套

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
int ConnectPeer2Peer(Conn *pA, Conn* pB, Manager *manager)
{
    if ( pA->isConnected() ) {
        manager->Prepare(pA);
        if ( pB->isConnected() ) {
            manager->Prepare(pB);
            if ( manager->ConnectTogther(pA, pB) ) {
                pA->Write("connected");
                pB->Write("connected");
                return S_OK;
            }else{
                return S_ERROR;
            }
        }else {
            pA->Write("Peer is not Ready, waiting...");
            return S_RETRY;
        }
    }else{
        if ( pB->isConnected() ) {
            manager->Prepare();
            pB->Write("Peer is not Ready, waiting...");
            return S_RETRY;
        }else{
            pA->Close();
            pB->Close();
            return S_ERROR;
        }
    }
    //Shouldn't be here!
    return S_ERROR;
}

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
int ConnectPeer2Peer(Conn *pA, Conn* pB, Manager *manager)
{
    if ( pA->isConnected() ) {
        manager->Prepare(pA);
    }
    if ( pB->isConnected() ) {
        manager->Prepare(pB);
    }
    // pA = YES && pB = NO
    if (pA->isConnected() && ! pB->isConnected()  ) {
        pA->Write("Peer is not Ready, waiting");
        return S_RETRY;
    // pA = NO && pB = YES
    }else if ( !pA->isConnected() && pB->isConnected() ) {
        pB->Write("Peer is not Ready, waiting");
        return S_RETRY;
    // pA = YES && pB = YES
    }else if (pA->isConnected() && pB->isConnected()  ) {
        if ( ! manager->ConnectTogther(pA, pB) ) {
            return S_ERROR;
        }
        pA->Write("connected");
        pB->Write("connected");
        return S_OK;
    }
    // pA = NO, pB = NO
    pA->Close();
    pB->Close();
    return S_ERROR;
}

延伸思考

对于 if-else 语句来说,一般来说,就是检查两件事:错误状态

检查错误

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

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

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

检查状态

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

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

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

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

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

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

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

总结

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

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

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

3)对于出错处理,使用try-catch异常处理和RAII机制。返回码的出错处理有很多问题,比如:A) 返回码可以被忽略,B) 出错处理的代码和正常处理的代码混在一起,C) 造成函数接口污染,比如像atoi()这种错误码和返回值共用的糟糕的函数。

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

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

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/452518.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

Django博客--4.开发博客文章详情页

文章目录0.思路引导1.设计文章详情页的 URL2.获取文章的URL3.编写 detail 视图函数4.编写详情页模板5.更改主页中跳转详情页的地址链接6.模板继承--抽取base.html7.模板继承--修改 index.html使其继承base.html8.模板继承--修改detail.html使其继承base.html9.结果展示0.思路引…

10、并发容器,ConcurrentHashMap

Java 提供了不同层面的线程安全支持。在传统集合框架内部&#xff0c;除了 Hashtable 等同步容器&#xff0c;还提供了所谓的同步包装器&#xff08;Synchronized Wrapper&#xff09;&#xff0c;我们可以调用 Collections 工具类提供的包装方法&#xff0c;来获取一个同步的包…

程序员的本质

Computers are useless. They can only give you answers. – Picasso计算机没有什么作用。他们只能告诉你答案。——毕加索很多人&#xff08;包括我岳母&#xff09;认为计算机变得如此智能&#xff0c;所以在不久的未来将不再需要程序员。另外一些人认为程序员是天才&#x…

模式-视图-控制器模式2.0

1 MVC的实现   1.1 分析应用问题&#xff0c;对系统进行分离   分析应用问题&#xff0c;分离出系统的内核功能、对功能的控制输入、系统的输出行为三大部分。设计模型部件使其封装内核数据和计算功能&#xff0c;提供访问显示数据的操作&#xff0c;提供控制内部行为的操作…

总体设计的原理

1 模块化 2 抽象 3 逐步求精 4 信息隐藏和局部化 5 模块独立

android 手动回收对象,Android Studio Studio回收列表中的JSON对象

我想在recyclerview中显示一些JSON对象&#xff0c;并且希望它们在日期之后排序&#xff0c;我该如何实现&#xff1f;下面是下载从JSON URL的数据的方法&#xff1a;Android Studio Studio回收列表中的JSON对象public void downloadFromSkistar(){try{URL url new URL("…

剖析管理所有大数据组件的可视化利器:Hue

欢迎关注大数据和人工智能技术文章发布的微信公众号&#xff1a;清研学堂&#xff0c;在这里你可以学到夜白&#xff08;作者笔名&#xff09;精心整理的笔记&#xff0c;让我们每天进步一点点&#xff0c;让优秀成为一种习惯&#xff01; 日常的大数据使用都是在服务器命令行中…

Django博客--5.让博客支持 Markdown 语法和代码高亮

文章目录0.前言1.安装 Python Markdown2.在 detail 视图中解析 Markdown3.safe 标签4.代码高亮5.效果展示0.前言 Markdown 是一种 HTML 文本标记语言&#xff0c;只要遵循它约定的语法格式&#xff0c;Markdown 的解析工具就能够把 Markdown 文档转换为标准的 HTML 文档&#…

耦合

模块的独立性很重要&#xff0c;因为有效的模块化(即具有独立的模块)的软件比较容易开发出来。 独立的模块比较容易测试和维护。 模块的独立程度可以由两个定性标准度量&#xff0c;这两个标准分别称为内聚和耦合。 耦合 耦合是对一个软件结构内不同模块之间互连程度的度量。…

成为更优秀的开发人员:第二步-知道你的核心竞争力

编者按&#xff1a;原文作者罗布沃林&#xff08;Rob Walling&#xff09;从事Web应用开发10年之久&#xff0c;担任过业内顾问、自由开发人员和全球最大的信用卡预付公司City of Pasadena的开发经理。现居住于加州中部城市弗雷斯诺&#xff08;Fresno&#xff09;。关注并指导…

android 字体间间隔,TextView设置行间距、字体间距

一、设置行间距1、设置行间距&#xff1a;android:lineSpacingExtra&#xff0c;取值范围&#xff1a;正数、负数和0&#xff0c;正数表示增加相应的大小&#xff0c;负数表示减少相应的大小&#xff0c;0表示无变化2、设置行间距的倍数&#xff1a;android:lineSpacingMultipl…

破解mysql数据库的密码

发现的1小问题 语句打错以后应该退出本语句,再继续打新语句.也可以打\c,退出本语句. 如何破解数据库的密码: 1:通过任务管理器或者服务管理,关掉mysqld(服务进程) 2:通过命令行特殊参数开启mysqld Mysqld --skip-grant-tables 3:此时,mysqld服务进程已经打开,并且,不需要权限检…

Diango博客--6.Markdown 文章自动生成目录

文章目录0.思路引导1.在文中插入目录2.在页面的任何地方插入目录3.美化标题的锚点 URL0.思路引导 Markdown 在解析内容的同时还可以自动提取整个内容的目录结构&#xff0c;本文内容将从以下几个方面展开&#xff1a; 1&#xff09;在文中插入目录&#xff1b; 2&#xff09;在…

Java中对象和引用的理解

2019独角兽企业重金招聘Python工程师标准>>> 偶然想起Java中对象和引用的基本概念&#xff0c;为了加深下对此的理解和认识&#xff0c;特地整理一下相关的知识点&#xff0c;通过具体实例从两者的概念和区别两方面去更形象的认识理解&#xff0c;再去记忆。12一、对…

android怎样封装,如何封装属于自己的博客网站安卓APP 源码家园

说实话我今天在写这个文章的时候是我使用易语言(E4A\易安卓)的第一天&#xff0c;我也是易小白&#xff0c;但是的确可以用&#xff01;我为什么写这个文章呢&#xff1f;因为之前我也想封装自己的网站&#xff0c;然后去网上找的在线封装生成APP&#xff0c;果然能封装好了&am…

程序员常犯的5个非技术性错误

一个好的软件开发人员需要培养两种技能&#xff1a;技术技能和非技术技能。不幸的是一些开发者只注重技术的部分&#xff0c;以致养成一些陋习&#xff0c;下面是最常犯的5个非技术性错误&#xff1a; 0. 缺乏自律 Jim Rohn曾经说过&#xff1a;自律是目标和成果之间的桥梁。我…

Redis进阶实践之二十 Redis的配置文件使用详解

一、引言   写完上一篇有关redis使用lua脚本的文章&#xff0c;就有意结束Redis这个系列的文章了&#xff0c;当然了&#xff0c;这里的结束只是我这个系列的结束&#xff0c;但是要学的东西还有很多。但是&#xff0c;好多天过去了&#xff0c;总是感觉好像还缺点什么…

web流程设计器 工作流的 整合视频教程 activiti画图 SSM和独立部署

本视频为activiti工作流的web流程设计器整合视频教程整合Acitiviti在线流程设计器(Activiti-Modeler 5.21.0 官方流程设计器&#xff09;本视频共讲了两种整合方式1. 流程设计器和其它工作流项目分开部署的方式2. 流程设计器和SSM框架项目整合在一起的方式视频大小 1.13 GB ~【…

Diango博客--7.自动生成文章摘要

文章目录0.思路引导1.方法一&#xff1a;覆写 save 方法2.方法二&#xff1a;使用 truncatechars 模板过滤器0.思路引导 博客文章的模型有一个 excerpt 字段&#xff0c;这个字段用于存储文章的摘要。 若在 django admin 后台手动为文章输入摘要&#xff0c;每次手动输入摘要…