C++ 把代码里的 ‘else’ 丢掉!

简介: C++ 把代码里的 ‘else’ 丢掉!

在任何一个代码库中,有 80% 的代码负责处理“正常路径”(即软件预期要做的事情),而其余的 20% 则用于处理错误、异常和边界情况。

当我们学习编程时,很自然地会遇到 if-else 语句(这个语句在多数流行的编程语言中都存在)。我们的大脑会立即将 if 与正常路径联系起来,而将 else 与边界情况联系起来。编程中普遍存在一种心理机制:通过在一个大的 if 代码块中包裹主要逻辑,程序员会觉得更加安心。他们会认为这样做能够防止不当输入或异常情况影响代码的主要功能。至于其他情况相对次要,放到 else 里面就好了。

这种做法经常会导致以下这样的代码:

if (someConditionIsMet) {
    // ...
    // ...
    // ...
    // 接下来是 100 行代码
    // ...
    // ...
    // ...
    // 还有 100 行
    // ...
    // ...
    // ...
} else {
  // 现在,处理边缘情况
}
return someResult;

其中一个问题是,边界情况的处理被放在了最后,这使得在上面的代码块添加代码时,很容易忽视 else 内的逻辑。我敢说,大多数人读这段代码时甚至不会注意到 else的存在,直到一个边界情况迫使他们更深入地阅读这段代码。

多层嵌套的陷阱

更糟糕的是,人们倾向于在多个层级上也运用这种模式。因此,写出来的代码更像是这样:

if (someConditionIsMet) {
    // ...
    // ...
    // ...
    // 接下来是 100 行代码
    // ...
    // ...
    // ...
    // 还有 100 行
    if (someOtherConditionIsMet) {
        // ...
        // ...
        // ...
        // 接下来是 100 行代码
        // ...
        // ...
        // ...
        if (yetAnotherConditionIsMet) {
            // ...
            // ...
            // ...
            // 接下来是 100 行代码
            // ...
            // ...
            // ...
            } else {
            // 现在,处理边缘情况
            }
        // ...
        // ...
        // ...
    } else {
        // 现在,处理边缘情况
        return someOtherResult;
    }
    // ...
    // ...
    // ...
} else {
// 现在,处理边缘情况
}
return someResult;

代码的多层嵌套是存在很大隐患,也给代码库增加了很多不必要的复杂性。人脑一次只能处理几件不同的事情,因此当面临需要深入分析多个代码层级时,很容易忘记上一层的关键逻辑,导致一些不必要的错误。这也通常是一些 Pull Request 的代码审查发现问题被打回去重新修改的一个主要原因。我们的业务流程已经足够复杂了,多层嵌套又进一步增加了其复杂度。

抛弃 else,优先处理边缘情况

如果我们抛弃 if-else 块中的 else 并优先处理这块逻辑,情况会怎么样呢?如果我们不期望某件事经常发生,难到不是先检查它、并在发生时立即返回更好吗?

先处理小的边界情况,如果必要的话提前返回;否则,将主流程保留在函数的最外层。

if (!someConditionIsMet) {
  // 首先处理那个边缘情况
  return someResultOrNothing;
}
// 主流程可以继续,不需要额外的保护块
// ...
// ...
// ...
// 再加 100 行代码
// ...
// ...
// ...
// 还有 100 行
return someResult;
if (!someConditionIsMet) {
  // 首先处理那个边缘情况
  return someResultOrNothing;
}
if (!someOtherConditionIsMet) {
  // 首先处理那个边缘情况
  return someResultOrNothing;
}
if (!yetAnotherConditionIsMet) {
  // 首先处理那个边缘情况
  return someResultOrNothing;
}
// 主流程可以继续,不需要额外的保护块
// ...
// ...
// ...
// 再加 100 行代码
// ...
// ...
// ...
// 还有 100 行
return someResult;

抛弃 else 就可以减少嵌套层数,有效降低代码复杂度。能够让代码更简单,结构更清晰,更容易维护。由于边界情况在函数的顶部得到了处理,开发者在后续添加新代码时不太可能忽略这些情况,从而降低了引入错误的风险。处理边缘情况并早期返回可以减少不必要的计算,从而可能提高代码的执行效率。简化的代码结构更容易被同事理解,从而使代码审查过程更加顺畅,减少了潜在错误和不良实践的传播。


推荐一个零声学院项目课,个人觉得老师讲得不错,分享给大家:

零声白金学习卡(含基础架构/高性能存储/golang云原生/音视频/Linux内核)

https://xxetb.xet.tech/s/VsFMs


相关文章
|
3月前
|
C++
C++ 语言异常处理实战:在编程潮流中坚守稳定,开启代码可靠之旅
【8月更文挑战第22天】C++的异常处理机制是确保程序稳定的关键特性。它允许程序在遇到错误时优雅地响应而非直接崩溃。通过`throw`抛出异常,并用`catch`捕获处理,可使程序控制流跳转至错误处理代码。例如,在进行除法运算或文件读取时,若发生除数为零或文件无法打开等错误,则可通过抛出异常并在调用处捕获来妥善处理这些情况。恰当使用异常处理能显著提升程序的健壮性和维护性。
74 2
|
3月前
|
算法框架/工具 C++ Python
根据相机旋转矩阵求解三个轴的旋转角/欧拉角/姿态角 或 旋转矩阵与欧拉角(Euler Angles)之间的相互转换,以及python和C++代码实现
根据相机旋转矩阵求解三个轴的旋转角/欧拉角/姿态角 或 旋转矩阵与欧拉角(Euler Angles)之间的相互转换,以及python和C++代码实现
223 0
|
4天前
|
算法 安全 C++
提高C/C++代码的可读性
提高C/C++代码的可读性
14 4
|
1月前
|
Linux C语言 C++
vsCode远程执行c和c++代码并操控linux服务器完整教程
这篇文章提供了一个完整的教程,介绍如何在Visual Studio Code中配置和使用插件来远程执行C和C++代码,并操控Linux服务器,包括安装VSCode、安装插件、配置插件、配置编译工具、升级glibc和编写代码进行调试的步骤。
186 0
vsCode远程执行c和c++代码并操控linux服务器完整教程
|
2月前
|
C++
继续更新完善:C++ 结构体代码转MASM32代码
继续更新完善:C++ 结构体代码转MASM32代码
|
2月前
|
C++ Windows
HTML+JavaScript构建C++类代码一键转换MASM32代码平台
HTML+JavaScript构建C++类代码一键转换MASM32代码平台
|
2月前
|
C++
2合1,整合C++类(Class)代码转换为MASM32代码的平台
2合1,整合C++类(Class)代码转换为MASM32代码的平台
|
2月前
|
前端开发 C++ Windows
C++生成QML代码与QML里面集成QWidget
这篇文章介绍了如何在C++中生成QML代码,以及如何在QML中集成QWidget,包括使用Qt Widgets嵌入到QML界面中的技术示例。
|
3月前
|
程序员 C++ 开发者
C++命名空间揭秘:一招解决全局冲突,让你的代码模块化战斗值飙升!
【8月更文挑战第22天】在C++中,命名空间是解决命名冲突的关键机制,它帮助开发者组织代码并提升可维护性。本文通过一个图形库开发案例,展示了如何利用命名空间避免圆形和矩形类间的命名冲突。通过定义和实现这些类,并在主函数中使用命名空间创建对象及调用方法,我们不仅解决了冲突问题,还提高了代码的模块化程度和组织结构。这为实际项目开发提供了宝贵的参考经验。
61 2
|
3月前
|
C++
拥抱C++面向对象编程,解锁软件开发新境界!从混乱到有序,你的代码也能成为高效能战士!
【8月更文挑战第22天】C++凭借其强大的面向对象编程(OOP)能力,在构建复杂软件系统时不可或缺。OOP通过封装数据和操作这些数据的方法于对象中,提升了代码的模块化、重用性和可扩展性。非OOP方式(过程化编程)下,数据与处理逻辑分离,导致维护困难。而OOP将学生信息及其操作整合到`Student`类中,增强代码的可读性和可维护性。通过示例对比,可以看出OOP使C++代码结构更清晰,特别是在大型项目中,能有效提高开发效率和软件质量。
32 1