使用单个出口点确实在调试中提供了优势，因为它允许您在函数的末尾设置单个断点，以查看实际将返回的值。

作为指导原则，我投票支持单次返回。这有助于一个常见的代码清理处理…例如，看看下面的代码…

void ProcessMyFile (char *szFileName)
{
   FILE *fp = NULL;
   char *pbyBuffer = NULL:

   do {

      fp = fopen (szFileName, "r");

      if (NULL == fp) {

         break;
      }

      pbyBuffer = malloc (__SOME__SIZE___);

      if (NULL == pbyBuffer) {

         break;
      }

      /*** Do some processing with file ***/

   } while (0);

   if (pbyBuffer) {

      free (pbyBuffer);
   }

   if (fp) {

      fclose (fp);
   }
}

正如Kent Beck在《实现模式》中讨论保护子句时指出的那样，使一个例程具有单一的入口和出口点……

是为了防止可能的混淆 当你在许多地方跳来跳去 同一例程中的位置。这让 当应用到FORTRAN或 汇编语言程序 有大量的全球数据，甚至 理解哪些语句是 执行是一项艰苦的工作……使用小方法和大部分本地数据，它是不必要的保守。”

我发现用保护子句编写的函数要比一长串嵌套的if then else语句容易理解得多。

我认为在不同的情况下，不同的方法更好。例如，如果您应该在返回之前处理返回值，则应该有一个退出点。但在其他情况下，使用多次返回会更舒服。

一个音符。如果在某些情况下，你应该在返回之前处理返回值，但不是所有情况下，最好的解决方案(IMHO)是定义一个像ProcessVal这样的方法，并在返回之前调用它:

var retVal = new RetVal();

if(!someCondition)
    return ProcessVal(retVal);

if(!anotherCondition)
   return retVal;

我相信多次返回通常是好的(在我用c#编写的代码中)。单返回样式是从C语言中保留下来的，但是您可能没有用C语言编写代码。

在所有编程语言中，没有法律要求一个方法只有一个退出点。有些人坚持这种风格的优越性，有时他们把它提升为“规则”或“法律”，但这种信念没有任何证据或研究支持。

在C代码中，多个返回样式可能是一个坏习惯，资源必须显式地去分配，但Java、c#、Python或JavaScript等语言具有自动垃圾收集和try. finally块(以及在c#中使用块)等构造，并且这个参数不适用-在这些语言中，需要集中的手动资源回收是非常罕见的。

在某些情况下，单个返回值可读性更好，而在某些情况下则不是这样。看看它是否减少了代码行数，使逻辑更清晰，或减少了大括号、缩进或临时变量的数量。

因此，根据你的艺术感受使用尽可能多的返回，因为这是一个布局和可读性问题，而不是技术问题。

我在我的博客上详细地讨论过这个问题。

如果可以只写下一个观点，那就是我的观点:

我完全不同意“单返回语句理论”，认为它在代码可读性、逻辑和描述方面都是推测性的，甚至是破坏性的。

使用一次-一次返回的习惯对于纯过程式编程来说都很糟糕，更不用说更高级的抽象(函数式、组合式等)了。此外，我希望所有以这种风格编写的代码都经过一些特殊的重写解析器，使其具有多个返回语句!

一个函数(如果它真的是一个函数/查询，根据“查询-命令分离”注意-见埃菲尔编程语言。例如)必须定义与控制流场景一样多的返回点。它在数学上更加清晰和一致;它是编写函数(即查询)的方法。

但对于你的特工收到的突变信息——程序调用，我不会那么激进。