在 void 方法中使用 return 是不好的做法吗？

发布于 2024-08-01 22:30:05 字数 309 浏览 6 评论 0原文

想象一下下面的代码：

void DoThis()
{
    if (!isValid) return;

    DoThat();
}

void DoThat() {
    Console.WriteLine("DoThat()");
}

在 void 方法中使用 return 可以吗？它有任何性能损失吗？或者编写这样的代码会更好：

void DoThis()
{
    if (isValid)
    {
        DoThat();
    }
}

原文

Imagine the following code:

void DoThis()
{
    if (!isValid) return;

    DoThat();
}

void DoThat() {
    Console.WriteLine("DoThat()");
}

Is it OK to use a return inside a void method? Does it have any performance penalty? Or it would be better to write a code like this:

void DoThis()
{
    if (isValid)
    {
        DoThat();
    }
}

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

_失温 2024-08-08 22:30:05

在这种情况下，您的第二个示例是更好的代码，但这与从 void 函数返回无关，这只是因为第二个代码更直接。但从 void 函数返回是完全没问题的。

回复收藏 0 原文

彡翼 2024-08-08 22:30:05

在这一点上，我不同意你们所有年轻自吹自擂者的观点。

在方法中间使用 return 是一种非常糟糕的做法，无论是 void 还是其他方法，原因已故的 Edsger W. Dijkstra 在近四十年前就已经清楚地阐述过，从著名的“GOTO 语句被认为是有害的”开始”，并继续阅读 Dahl、Dijkstra 和 Hoare 所著的“结构化编程”。

基本规则是每个控制结构和每个模块都应该有一个入口和一个出口。模块中间的显式返回打破了该规则，并使推理程序的状态变得更加困难，这反过来又使判断程序是否正确变得更加困难（这是一个更强的属性）而不是“它是否有效”）。

“GOTO 语句被认为有害”和“结构化编程”拉开了 20 世纪 70 年代“结构化编程”革命的序幕。这两部分是我们今天拥有 if-then-else、while-do 和其他显式控制结构的原因，也是高级语言中的 GOTO 语句出现在濒危物种列表中的原因。（我个人的观点是，它们需要列入灭绝物种名单。）

值得注意的是，消息流调制器是第一个在第一次尝试中就通过验收测试的军事软件，没有偏差、豁免或“是的，但是”这样的废话，是用一种甚至没有 GOTO 语句的语言编写的。

还值得一提的是，Nicklaus Wirth 在 Oberon-07（Oberon 编程语言的最新版本）中更改了 RETURN 语句的语义，使其成为类型化过程（即函数）声明的尾随部分，而不是函数体中的可执行语句。他对这一变化的解释说，他这样做正是因为以前的形式违反了结构化编程的单出口原则。

回复收藏 0 原文

对你的占有欲 2024-08-08 22:30:05

void 方法中的返回还不错，是反转 if 的常见做法 语句来减少嵌套。

减少方法上的嵌套可以提高代码的可读性和可维护性。

实际上，如果您有一个没有任何 return 语句的 void 方法，编译器将始终生成 ret 指令在其末尾。

回复收藏 0 原文

避讳 2024-08-08 22:30:05

使用防护（与嵌套代码相反）的另一个重要原因是：如果另一个程序员将代码添加到您的函数中，那么他们将在更安全的环境中工作。

考虑：

void MyFunc(object obj)
{
    if (obj != null)
    {
        obj.DoSomething();
    }
}

与：

void MyFunc(object obj)
{
    if (obj == null)
        return;

    obj.DoSomething();
}

现在，想象另一个程序员添加了这一行： obj.DoSomethingElse();

void MyFunc(object obj)
{
    if (obj != null)
    {
        obj.DoSomething();
    }

    obj.DoSomethingElse();
}

void MyFunc(object obj)
{
    if (obj == null)
        return;

    obj.DoSomething();
    obj.DoSomethingElse();
}

显然这是一个简单的情况，但程序员在第一个（嵌套代码）实例中的程序中添加了崩溃。在第二个示例（带有防护的提前退出）中，一旦通过防护，您的代码就不会意外使用空引用。

当然，一个伟大的程序员不会（经常）犯这样的错误。但预防胜于治疗——我们可以以完全消除这种潜在错误源的方式编写代码。嵌套会增加复杂性，因此最佳实践建议重构代码以减少嵌套。

There is another great reason for using guards (as opposed to nested code): If another programmer adds code to your function, they are working in a safer environment.

Consider:

void MyFunc(object obj)
{
    if (obj != null)
    {
        obj.DoSomething();
    }
}

versus:

void MyFunc(object obj)
{
    if (obj == null)
        return;

    obj.DoSomething();
}

Now, imagine another programmer adds the line: obj.DoSomethingElse();

void MyFunc(object obj)
{
    if (obj != null)
    {
        obj.DoSomething();
    }

    obj.DoSomethingElse();
}

void MyFunc(object obj)
{
    if (obj == null)
        return;

    obj.DoSomething();
    obj.DoSomethingElse();
}

Obviously this is a simplistic case, but the programmer has added a crash to the program in the first (nested code) instance. In the second example (early-exit with guards), once you get past the guard, your code is safe from unintentional use of a null reference.

Sure, a great programmer doesn't make mistakes like this (often). But prevention is better than cure - we can write the code in a way that eliminates this potential source of errors entirely. Nesting adds complexity, so best practices recommend refactoring code to reduce nesting.

回复收藏 0 原文

幸福还没到 2024-08-08 22:30:05

不好的做法？？？决不。事实上，如果验证失败，最好通过尽早从方法返回来处理验证。否则会导致大量嵌套的 if 和 if 语句。其他的。提前终止可以提高代码的可读性。

另请检查类似问题的答复：我应该使用return/Continue 语句而不是 if-else？

回复收藏 0 原文

Smile简单爱 2024-08-08 22:30:05

这不是一个坏习惯（出于已经说明的所有原因）。然而，一个方法中的返回越多，它就越有可能被分割成更小的逻辑方法。

回复收藏 0 原文

妄司 2024-08-08 22:30:05

第一个示例是使用保护语句。来自维基百科：

在计算机编程中，守卫是
必须计算的布尔表达式
如果程序执行为 true
继续在有问题的分支。

我认为在方法的顶部有一堆守卫是一种完全可以理解的编程方式。它基本上是说“如果其中任何一个为真，则不要执行此方法”。

所以一般来说它会像这样：

void DoThis()
{
  if (guard1) return;
  if (guard2) return;
  ...
  if (guardN) return;

  DoThat();
}

我认为这样更具可读性：

void DoThis()
{
  if (guard1 && guard2 && guard3)
  {
    DoThat();
  }
}

The first example is using a guard statement. From Wikipedia:

In computer programming, a guard is a
boolean expression that must evaluate
to true if the program execution is to
continue in the branch in question.

I think having a bunch of guards at the top of a method is a perfectly understandable way to program. It is basically saying "do not execute this method if any of these are true".

So in general it would like this:

void DoThis()
{
  if (guard1) return;
  if (guard2) return;
  ...
  if (guardN) return;

  DoThat();
}

I think that's a lot more readable then:

void DoThis()
{
  if (guard1 && guard2 && guard3)
  {
    DoThat();
  }
}

回复收藏 0 原文

〗斷ホ乔殘χμё〖 2024-08-08 22:30:05

没有性能损失，但是第二段代码更具可读性，因此更容易维护。

回复收藏 0 原文

软的没边 2024-08-08 22:30:05

这完全没问题，并且不会造成“性能损失”，但永远不要编写没有括号的“if”语句。

总是

if( foo ){
    return;
}

更具可读性；并且您永远不会意外地假设代码的某些部分不在该语句内，而实际上它们并不在该语句内。

It's perfectly okay and no 'performance penalty', but never ever write an 'if' statement without brackets.

Always

if( foo ){
    return;
}

It's way more readable; and you'll never accidentally assume that some parts of the code are within that statement when they're not.

回复收藏 0 原文

滥情稳全场 2024-08-08 22:30:05

使用防护措施时，请确保遵循某些准则，以免混淆读者。

函数做一件事
守卫仅作为函数中的第一个逻辑引入
未嵌套部分包含函数的核心意图

示例

// guards point you to the core intent
void Remove(RayCastResult rayHit){

  if(rayHit== RayCastResult.Empty)
    return
    ;
  rayHit.Collider.Parent.Remove();
}

// no guards needed: function split into multiple cases
int WonOrLostMoney(int flaw)=>
  flaw==0 ? 100 :
  flaw<10 ? 30 :
  flaw<20 ? 0 :
  -20
;

While using guards, make sure you follow certain guidelines to not confuse readers.

the function does one thing
guards are only introduced as the first logic in the function
the unnested part contains the function's core intent

Example

// guards point you to the core intent
void Remove(RayCastResult rayHit){

  if(rayHit== RayCastResult.Empty)
    return
    ;
  rayHit.Collider.Parent.Remove();
}

// no guards needed: function split into multiple cases
int WonOrLostMoney(int flaw)=>
  flaw==0 ? 100 :
  flaw<10 ? 30 :
  flaw<20 ? 0 :
  -20
;

回复收藏 0 原文