退出带有空返回语句的函数是好还是坏？答案

【问题标题】：Is exiting a function with an empty return statement good/bad practice?退出带有空返回语句的函数是好还是坏？
【发布时间】：2016-02-27 06:11:04
【问题描述】：

我看过很多例子，这让我非常好奇

两个例子如下：

在 void 函数的末尾加上 return;，这太荒谬了。
在函数中间使用return; 来突破它。我不喜欢它。

以下示例可能会阐明第二种情况（第一种情况很明显）：

- SomeMethodThatReturnsSomethingOrNot(var param1){

    if (param1 == null){

         CallThisMethod();
         return;
    }

    CallThisOtherMethod(param1);

}

对很多人来说，这很好，很清楚。对我来说，充其量可以接受。

为什么不简单地使用if else？您无需在代码中间使用 return 任何内容，它不会降低可读性，而且，我不知道还能说什么，这对我来说只是一种更好的做法。

- SomeMethodThatReturnsSomethingOrNot(var param1){

        if (param1 == null){
             CallThisMethod();
        }else{
             CallThisOtherMethod(param1);
        }

    }

现在我想强调这里示例的简单性，我知道可以制作一些更性感的东西，但让我们假装它比null 检查更复杂一点，这需要相同类型的if-return而是of if-else 技术。

那么，大家的想法是什么？

我一直强烈反对在方法无效或我实际上不想返回任何东西时返回一些东西。如果我最终陷入这种情况，我想重新考虑我的架构，因为它不应该发生。

我是完全错误/正确还是这里有一些讨论空间？

【问题讨论】：

如果CallThisMethod(); 是一些代码，而CallThisOtherMethod 将是很多代码，这是有意义的
主要基于意见投票结束。
@Grundy 如果超过 1 或 2 行，无论如何它都会隐藏在一个方法中，所以大多数时候它与我的示例非常相似（名称除外）。
@zenith 你是对的，也许我应该把它放在programmers.stackexchange中
@Zil，并非在所有情况下都可以将一些代码行移至方法

标签： if-statement coding-style return

【解决方案1】：

您可能有兴趣了解 SESE（单进单出）的主题以及 Dijkstra 对促使这种风格的主题的想法。

值得注意的是，Dijkstra 的想法经常被误解。在一个很多人直接用汇编编写代码的时代，他提倡实践。在汇编中，您通常可以从任何指令跳转到任何其他指令。这就是“单项”概念的来源：从一个函数跳到另一个函数的中间是非常令人困惑的。

“单次退出”通常被误解为仅从一个位置退出一个函数。这实际上意味着将一个函数退出到一个地方。如果您从函数返回到调用它的站点以外的地方，就会变得非常混乱。

尽管如此，今天很多人仍然认为“单退出”是指“退出函数中的一个位置”，并且倡导者经常宣传您所建议的风格。

我不会讨论哪个更好或更坏。这不可避免地会是主观的。但也有一些值得思考的事情。

显式清理

在一个函数中只从一个地方退出的想法在需要在许多函数中对其资源进行显式清理的时代很流行——就像这样：

function f()
    allocate_resources()
    ...
    deallocate_resources()
end

我们可以看看我们是否在这样的函数中引入了任何类型的提前返回语句，以至于我们很容易忘记释放资源并最终导致某种资源泄漏。在这些情况下，仅在函数末尾支持 return 语句的建议对于防止人为错误变得更加有用。

异常处理

异常处理现在是许多现代语言的共同特征。使用异常处理，整个函数都可以有隐式退出。示例：

function f()
    list = create_list()   -- could throw
    list.insert(123)       -- could throw
    connect_to_server()    -- could throw
    if x == 0 then
         add_some_widget() -- could throw
    end
end

在这些情况下，由于抛出异常，任何代码行都可能具有函数的隐式退出点。因此，不可能使控制流完全可预测。同样，自动化资源管理也不可避免地需要由编译器（或垃圾收集器）自动清理资源，而不是由开发人员手动完成，因为手动完成这么多资源变得太不切实际了函数中的隐式退出点。

结论

所以这些是需要考虑的一些因素。我个人处于光谱的中低端（如果“低”意味着将回报放在任何地方，而“高”意味着只在底部）。但这完全取决于您在哪里找到自己的舒适区，以及您发现哪种代码最容易理解和维护。

在我的拙见中，我们可能会睁一只眼闭一只眼地试图分析一个函数究竟是如何写到每一行代码中的优点，但我必须求助于一种务实的观点，比如只是测试很好，确保接口和文档清晰，确保实现可能通过基本的试金石，不会导致人们的大脑爆炸，然后发布。

【讨论】：