c++ - 没有 "if(...) return ...;"的 "else"是否被认为是好的风格？

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用资料或专业知识的支持，但这个问题可能会引发辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开， visit the help center寻求指导。

关闭 11年前.

这段代码:

if( someCondition )
    return doSomething();

return doSomethingElse();

对比这段代码:

if( someCondition )
    return doSomething();
else
    return doSomethingElse();

本质上，它们是相同的，但是什么是最好的风格/性能/...(当然，如果答案中有任何非自以为是的话)？还要考虑多个“if else's”的情况:

if( someCondition )
    return doSomething();
else if( someOtherCondition )
    return doSomethingDifferently();
//...
else
    return doSomethingElse();

谢谢!

Answer 1

当函数中有多个返回语句时，这称为“提前返回”。如果你做 Google search对于“提前返回”，您会发现一个接一个的链接表明它很糟糕。

我说的是废话。

人们声称早退是不好的，有两个主要原因和一个次要原因。我将通过它们并按顺序给出我的反驳。请记住，这是我的全部意见，最终您必须自己决定。

1. 原因:提前返回很难清理。

   反驳:就是这样RAII是为了。一个设计良好的程序不会以这样一种方式分配资源，即如果执行提前离开范围，这些资源就会泄漏。而不是这样做:

...

int foo()
{
  MyComplexDevice* my_device = new MyComplexDevice;
  // ...
  if( something_bad_hapened )
    return 0;
  // ...
  delete my_device;
  return 42;
}

你这样做:

int foo()
{
  std::auto_ptr<MyComplexDevice> my_device(new MyComplexDevice);
  if( something_bad_hapened )
    return 0;
  // ...
  return 42;
} 

并且提前返回不会导致资源泄漏。在大多数情况下，您甚至不需要使用 auto_ptr 因为您将创建数组或字符串，在这种情况下您将使用 vector、string 或类似的东西。

您应该像这样设计您的代码以保证稳健性，因为可能会出现异常。异常是一种提前返回的形式，就像显式的 return 语句一样，您需要准备好处理它们。 foo() 中的异常你可能不会处理，但 foo() 无论如何都不应该泄漏。

1. 原因:提前返回会使代码更加复杂。反驳:早期返回实际上使代码更简单。

函数应该有一个责任是一种普遍的哲学。我同意这一点。但是人们对此太过分了，并得出结论，如果一个函数有多个返回，它必须有多个责任。 (他们通过说函数的长度不应超过 50 行或其他任意数字来扩展这一点。)我说不。仅仅因为一个函数只有一个职责，并不意味着它不需要做很多事情来履行这个职责。

以打开数据库为例。这是一项责任，但它由许多步骤组成，每个步骤都可能出错。打开连接。登录。获取一个连接对象并返回它。 3 个步骤，每个步骤都可能失败。您可以将其分解为 3 个子步骤，但不要使用这样的代码:

int foo()
{ 
  DatabaseObject db = OpenDatabase(...);
}

你最终会拥有:

int foo()
{
  Connection conn = Connect(...);
  bool login = Login(...);
  DBObj db = GetDBObj(conn);
}

因此，您实际上只是将假定的多个职责移到调用堆栈中的更高位置。

1. 原因:多个返回点不是面向对象的。反驳:这实际上只是另一种说法“每个人都说多次返回不好，尽管我真的不知道为什么。”

换一种说法，这实际上只是试图将所有东西都塞进一个物体形状的盒子里，即使它不属于那里。当然，也许连接是一个对象。但是是登录吗？登录尝试不是(IMO)对象。这是一个手术。或者算法。尝试采用这种算法并将其塞进一个对象形状的盒子中是对 OOP 的无端尝试，只会导致代码更复杂、更难维护，甚至可能效率更低。