我通常支持多个return语句。它们是最容易阅读的。

在某些情况下，这并不好。有时从函数返回可能非常复杂。我记得有一种情况，所有函数都必须链接到多个不同的库。一个库期望返回值是错误/状态代码，而其他库则不期望。使用一个return语句可以节省时间。

我很惊讶没人提到goto。Goto并不是每个人都想让你相信的编程的祸害。如果必须在每个函数中只有一个return语句，请将它放在末尾，并根据需要使用gotos跳转到该return语句。绝对避免标记和箭头编程，它们既丑陋又运行缓慢。

I always avoid multiple return statements. Even in small functions. Small functions can become larger, and tracking the multiple return paths makes it harder (to my small mind) to keep track of what is going on. A single return also makes debugging easier. I've seen people post that the only alternative to multiple return statements is a messy arrow of nested IF statements 10 levels deep. While I certain agree that such coding does occur, it isn't the only option. I wouldn't make the choice between a multiple return statements and a nest of IFs, I'd refactor it so you'd eliminate both. And that is how I code. The following code eliminates both issues and, in my mind, is very easy to read:

public string GetResult()
{
    string rv = null;
    bool okay = false;

    okay = PerformTest(1);

    if (okay)
    {
        okay = PerformTest(2);
    }

    if (okay)
    {
        okay = PerformTest(3);
    }

    if (okay)
    {
        okay = PerformTest(4);
    };

    if (okay)
    {
        okay = PerformTest(5);
    }

    if (okay)
    {
        rv = "All Tests Passed";
    }

    return rv;
}

你知道有句谚语——情人眼里出西施。

有些人信得过NetBeans，有些人信得过IntelliJ IDEA，有些人信得过Python，有些人信得过PHP。

在一些商店，如果你坚持这样做，你可能会丢掉工作:

public void hello()
{
   if (....)
   {
      ....
   }
}

这个问题完全是关于可见性和可维护性。

I am addicted to using boolean algebra to reduce and simplify logic and use of state machines. However, there were past colleagues who believed my employ of "mathematical techniques" in coding is unsuitable, because it would not be visible and maintainable. And that would be a bad practice. Sorry people, the techniques I employ is very visible and maintainable to me - because when I return to the code six months later, I would understand the code clearly rather seeing a mess of proverbial spaghetti.

嘿，伙计(就像一个前客户曾经说过的)，做你想做的，只要你知道如何在我需要你解决它的时候解决它。

I remember 20 years ago, a colleague of mine was fired for employing what today would be called agile development strategy. He had a meticulous incremental plan. But his manager was yelling at him "You can't incrementally release features to users! You must stick with the waterfall." His response to the manager was that incremental development would be more precise to customer's needs. He believed in developing for the customers needs, but the manager believed in coding to "customer's requirement".

我们经常因为打破数据规范化、MVP和MVC边界而感到内疚。我们内联而不是构造函数。我们走捷径。

就我个人而言，我认为PHP是一种糟糕的实践，但我又知道什么呢?所有的理论争论都归结为试图满足一套规则

质量=精度，可维护性 和盈利能力。

所有其他规则都退居幕后。当然，这条规则永远不会消失:

懒惰是一种美德 程序员。

我通常的策略是在函数的末尾只有一个return语句，除非通过添加更多的return语句来大大降低代码的复杂性。事实上，我是Eiffel的粉丝，它通过没有return语句强制执行唯一的返回规则(只有一个自动创建的'result'变量来放入结果)。

当然，在某些情况下，有多个返回值的代码比没有返回值的代码更清晰。有人可能会说，如果一个函数太复杂，没有多个return语句就无法理解，那么就需要更多的返工，但有时对这种事情采取务实的态度是好的。

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

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);
   }
}

Structured programming says you should only ever have one return statement per function. This is to limit the complexity. Many people such as Martin Fowler argue that it is simpler to write functions with multiple return statements. He presents this argument in the classic refactoring book he wrote. This works well if you follow his other advice and write small functions. I agree with this point of view and only strict structured programming purists adhere to single return statements per function.