У Вас уже неявно есть несколько неявных операторов возврата, вызванных обработкой ошибок, таким образом имейте дело с нею.

, Как типично с программированием, тем не менее, существуют примеры как за, так и против практики возврата нескольких. Если это делает код более ясным, сделайте это так или иначе. Использование многих управляющих структур может помочь ( случай оператор, например).

Я использую несколько точек выхода для того, чтобы иметь ошибочный случай + обрабатывающий + возвращаемое значение максимально близко в близости.

Настолько имеющий необходимость для тестирования на условия a, b, c, которые должны быть верными и необходимо обработать каждого из них по-другому:

if (a is false) {
    handle this situation (eg. report, log, message, etc.)
    return some-err-code
}
if (b is false) {
    handle this situation
    return other-err-code
}
if (c is false) {
    handle this situation
    return yet-another-err-code
}

perform any action assured that a, b and c are ok.

a, b и c могли бы быть разными вещами, как входная проверка параметра, b является проверкой указателя к недавно выделенной памяти, и c является проверкой на значение в параметре.

Как альтернатива вложенной IFS, существует способ использовать do / while(false) для вспыхивания где угодно:

    function()
    {
        HRESULT error = S_OK;

        do
        {
            if(!SUCCEEDED(Operation1()))
            {
                error = OPERATION1FAILED;
                break;
            }

            if(!SUCCEEDED(Operation2()))
            {
                error = OPERATION2FAILED;
                break;
            }

            if(!SUCCEEDED(Operation3()))
            {
                error = OPERATION3FAILED;
                break;
            }
            if(!SUCCEEDED(Operation4()))
            {
                error = OPERATION4FAILED;
                break;
            }
        } while (false);

        return error;
    }

, Который получает Вас одна точка выхода, позволяет Вам иметь другое вложение операций, но все еще реальную глубинную структуру. Если Вам не нравится! СЛЕДОВАВШИЙ Вы могли всегда делать, ПЕРЕСТАЛ РАБОТАТЬ что. Такого рода вещь также позволяет Вам добавить другой код между любыми двумя другими проверками, не имея необходимость повторно располагать что-либо с отступом.

, Если Вы были действительно сумасшедшими, что целый if блок мог быть macroized также.: D

    #define BREAKIFFAILED(x,y) if (!SUCCEEDED((x))) { error = (Y); break; }

    do
    {
        BREAKIFFAILED(Operation1(), OPERATION1FAILED)
        BREAKIFFAILED(Operation2(), OPERATION2FAILED)
        BREAKIFFAILED(Operation3(), OPERATION3FAILED)
        BREAKIFFAILED(Operation4(), OPERATION4FAILED)
    } while (false);

Я обычно выступаю за несколько операторов возврата. Их является самым легким считать.

существуют ситуации, где это не хорошо. Иногда возврат из функции может быть очень сложным. Я вспоминаю один случай, где все функции должны были связаться в несколько различных библиотек. Значения ожидаемого дохода библиотеки, чтобы быть ошибкой/кодами статусов и другими не сделали. Наличие единственного оператора возврата может сэкономить время там.

я удивлен, что никто не упомянул goto. Goto не является отравой программирования этого, все сделали бы, чтобы Вы верили. Если у Вас должен быть просто единственный возврат в каждой функции, поместите ее в конец и используйте gotos для перехода к тому оператору возврата по мере необходимости. Определенно избегайте флагов и программирования стрелки, которые и ужасны и выполняются медленно.

Несколько выходят, хорошо, если Вы управляете им хорошо

, первый шаг должен определить причины выхода. Мой обычно - что-то вроде этого:
1. Никакая потребность выполнить функцию
2. Ошибка найдена
3. Раннее завершение
4. Нормальное завершение
я предполагаю, что можно сгруппироваться "1. Никакая потребность выполнить функцию" в "3. Раннее завершение" (очень раннее завершение, если Вы будете).

второй шаг должен позволить миру вне функции знать причину выхода. Псевдокод выглядит примерно так:

function foo (input, output, exit_status)

  exit_status == UNDEFINED
  if (check_the_need_to_execute == false) then
    exit_status = NO_NEED_TO_EXECUTE  // reason #1 
    exit

  useful_work

  if (error_is_found == true) then
    exit_status = ERROR               // reason #2
    exit
  if (need_to_go_further == false) then
    exit_status = EARLY_COMPLETION    // reason #3
    exit

  more_work

  if (error_is_found == true) then
    exit_status = ERROR
  else
    exit_status = NORMAL_COMPLETION   // reason #4

end function

, Очевидно, если это выгодно для перемещения глыбы работы на иллюстрации выше в отдельную функцию, необходимо сделать так.

, Если Вы хотите, можно быть более конкретными со статусом выхода, скажем, с несколькими кодами ошибки и ранними кодами завершения для точного определения причины (или даже местоположение) выхода.

, Даже если Вы вызываете эту функцию в ту, которая имеет только единственный выход, я думаю, что все еще необходимо определить статус выхода так или иначе. Вызывающая сторона должна знать, нормально ли использовать вывод, и это помогает обслуживанию.

Если Вы заканчиваете с больше, чем несколькими возвратами может быть что-то не так с Вашим кодом. Иначе я согласился бы, что иногда хорошо быть в состоянии возвратиться из нескольких мест в подпрограмме, особенно когда это делает инструмент для очистки кода.

Perl 6: Плохой Пример

sub Int_to_String( Int i ){
  given( i ){
    when 0 { return "zero" }
    when 1 { return "one" }
    when 2 { return "two" }
    when 3 { return "three" }
    when 4 { return "four" }
    ...
    default { return undef }
  }
}

был бы лучше записан как это

Perl 6: Хорошим Примером

@Int_to_String = qw{
  zero
  one
  two
  three
  four
  ...
}
sub Int_to_String( Int i ){
  return undef if i < 0;
  return undef unless i < @Int_to_String.length;
  return @Int_to_String[i]
}

Примечание, которое это, был просто быстрый пример

Моя обычная политика состоит в том, чтобы иметь только один оператор возврата в конце функции, если сложность кода значительно не уменьшается путем добавления больше. На самом деле я - скорее поклонник Eiffel, который осуществляет единственное правило возврата при наличии никакого оператора возврата (существует только автосозданная переменная 'результата', чтобы вставить Ваш результат).

, конечно, существует случаи, где код может быть сделан более ясным с несколькими возвратами, чем очевидная версия без них была бы. Можно было утверждать, что больше переделывает, необходим, если у Вас есть функция, которая слишком сложна, чтобы быть понятной без нескольких операторов возврата, но иногда хорошо быть прагматичным о таких вещах.

Единственная точка выхода - все другие равные вещи - делают код значительно более читаемым. Но существует выгода: популярная конструкция

resulttype res;
if if if...
return res;

является фальшивкой, "res =" не намного лучше, чем "возврат". Это имеет единственный оператор возврата, но несколько точек, где функция на самом деле заканчивается.

, Если у Вас есть функция с несколькими возвратами (или "res = "s), это часто - хорошая идея повредить его в несколько меньших функций с единственной точкой выхода.

Я сказал бы, что будет невероятно неблагоразумно решить произвольно против нескольких точек выхода, поскольку я нашел, что техника полезна на практике много раз , на самом деле я часто имею , осуществил рефакторинг существующий код к нескольким точкам выхода для ясности. Мы можем выдержать сравнение, два thus:-

string fooBar(string s, int? i) {
  string ret = "";
  if(!string.IsNullOrEmpty(s) && i != null) {
    var res = someFunction(s, i);

    bool passed = true;
    foreach(var r in res) {
      if(!r.Passed) {
        passed = false;
        break;
      }
    }

    if(passed) {
      // Rest of code...
    }
  }

  return ret;
}

подходов Сравнивают это с кодом, где несколько точек выхода permitted:-

string fooBar(string s, int? i) {
  var ret = "";
  if(string.IsNullOrEmpty(s) || i == null) return null;

  var res = someFunction(s, i);

  foreach(var r in res) {
      if(!r.Passed) return null;
  }

  // Rest of code...

  return ret;
}

, я думаю, что последний значительно более ясен. Насколько я могу сказать, что критика нескольких точек выхода является довольно архаичной точкой зрения в эти дни.

Я в настоящее время работаю над кодовой базой, где два из людей, работающих над нею вслепую, подписывают на "единственную точку выхода" теорию, и я могу сказать Вам, что на основе опыта, это - ужасная ужасная практика. Это делает код чрезвычайно трудным поддержать, и я покажу Вам почему.

С "единственной точкой выхода" теория, Вы неизбежно волнуете с кодом, который похож на это:

function()
{
    HRESULT error = S_OK;

    if(SUCCEEDED(Operation1()))
    {
        if(SUCCEEDED(Operation2()))
        {
            if(SUCCEEDED(Operation3()))
            {
                if(SUCCEEDED(Operation4()))
                {
                }
                else
                {
                    error = OPERATION4FAILED;
                }
            }
            else
            {
                error = OPERATION3FAILED;
            }
        }
        else
        {
            error = OPERATION2FAILED;
        }
    }
    else
    {
        error = OPERATION1FAILED;
    }

    return error;
}

Не только делает это делает код очень трудно, чтобы следовать, но теперь сказать позже, что необходимо возвратиться и добавить операцию промежуточный 1 и 2. Необходимо расположить с отступом примерно всю долбаную функцию и удачу, удостоверившись весь в Ваш, если/еще условия и фигурные скобки подходятся правильно.

Этот метод делает обслуживание кода чрезвычайно трудным и подверженным ошибкам.

Структурное программирование говорит, что у Вас должен только когда-либо быть один оператор возврата на функцию. Это должно ограничить сложность. Многие люди, такие как Martin Fowler утверждают, что более просто записать функции с несколькими операторами возврата. Он представляет этот аргумент в классике рефакторинг книга, которую он записал. Это работает хорошо, если Вы следуете его другому совету и пишете небольшие функции. Я соглашаюсь с этой точкой зрения, и только строгие пуристы структурного программирования придерживаются единственных операторов возврата на функцию.

Поскольку Kent Beck отмечает при обсуждении защитных пунктов в Шаблоны Реализации создание стандартной программы иметь однократную и точку выхода...

"должен был предотвратить беспорядок, возможный при вскакивании и из многих местоположений в той же стандартной программе. Это проявило здравый смысл, когда относился к ФОРТРАНУ или программам на языке ассемблера, записанным с большим количеством глобальных данных, где даже понимание, какие операторы выполнялись, было тяжелой работой... с маленькими методами и главным образом локальными данными, это напрасно консервативно".

я нахожу функцию записанной с защитными пунктами намного легче следовать, чем один длинный вложенный набор if then else операторы.

В функции, которая не имеет никаких побочных эффектов, нет никакого серьезного основания иметь больше, чем единственный возврат, и необходимо записать им в функциональном стиле. В методе с побочными эффектами вещи более последовательны (индексированный временем), таким образом, Вы пишете в обязательном стиле, с помощью оператора возврата в качестве команды, чтобы прекратить выполняться.

, Другими словами, если это возможно, способствуют этому стилю

return a > 0 ?
  positively(a):
  negatively(a);

по этому

if (a > 0)
  return positively(a);
else
  return negatively(a);

, Если Вы пишете несколько слоев вложенных условий, существует, вероятно, способ, которым можно осуществить рефакторинг это, с помощью списка предиката, например. Если Вы находите, что Ваша IFS и elses далеко друг от друга синтаксически, Вы могли бы хотеть разломать это на меньшие функции. Условный блок, который охватывает больше, чем экранный из текста, трудно считать.

нет никакого жесткого правила, которое относится к каждому языку. Что-то как наличие единственного оператора возврата не сделает Ваш код хорошим. Но хороший код будет иметь тенденцию позволять Вам писать Вашим функциям тот путь.

Я видел его в кодировании стандартов для C++, которые были похмельем от C, как будто у Вас нет RAII или другого автоматического управления памятью тогда, необходимо вымыться для каждого возврата, который или означает вырезание и вклейку очистки или goto (логически то же как 'наконец' на управляемых языках), оба из которых считают невоспитанностью. Если Ваши методы должны использовать интеллектуальные указатели и наборы в C++ или другой автоматической системе памяти, то нет веской причины его, и это становится всеми об удобочитаемости и большем количестве личного выбора.

В целом я пытаюсь иметь только единственную точку выхода от функции. Существуют времена, однако, что выполнение поэтому на самом деле заканчивает тем, что создало тело более комплексной функции, чем необходимо, в этом случае лучше иметь несколько точек выхода. Это действительно должен быть "личный выбор" на основе получающейся сложности, но целью должно быть как можно меньше точек выхода, не жертвуя сложностью и понятностью.

Наличие единственной точки выхода уменьшает , Цикломатическая Сложность и поэтому, в теории , уменьшает вероятность, что Вы введете ошибки в свой код при изменении его. Практика однако, имеет тенденцию предполагать, что необходим более прагматический подход. Я поэтому склонен стремиться иметь единственную точку выхода, но позволить моему коду иметь несколько, если это более читаемо.

Я сказал бы, что у Вас должно быть столько же как требуется или любой, которые делают инструмент для очистки кода (такой как защитные пункты ).

я лично никогда не слышал/видел, что любые "лучшие практики" говорят, что у Вас должен быть только один оператор возврата.

По большей части, я склонен выходить из функции как можно скорее на основе логического пути (защитные пункты являются превосходным примером этого).

Мое предпочтение было бы для единственного выхода, если это действительно не усложняет вещи. Я нашел, что в некоторых случаях, несколько существуют, точки могут замаскировать другие более значительные проблемы проектирования:

public void DoStuff(Foo foo)
{
    if (foo == null) return;
}

При наблюдении этого кода, я сразу спросил бы:

• 'нечто' является когда-либо пустым?
• Если так, сколько клиентов 'DoStuff' когда-нибудь вызывает функцию с пустым 'нечто'?

В зависимости от ответов на эти вопросы могло бы случиться так, что

1. проверка бессмысленна, поскольку это никогда не верно (т.е. это должно быть утверждение)
2. , проверка очень редко верна и таким образом, может быть лучше изменить те определенные функции вызывающей стороны, поскольку они должны, вероятно, принять некоторые другие меры так или иначе.

В обоих из вышеупомянутых случаев код может, вероятно, быть переделан с утверждением, чтобы гарантировать, что 'нечто' никогда не является пустым и соответствующие измененные вызывающие стороны.

существует две других причины (конкретный, я думаю к коду C++), где несколько существуют, может на самом деле иметь отрицательный влияние. Они - размер кода и оптимизация компилятора.

объекту C++ не-POD А в объеме в выходе функции назовут ее деструктор. Где существует несколько операторов возврата, может иметь место, что существуют различные объекты в объеме и таким образом, список деструкторов для вызова будет отличаться. Компилятор поэтому должен генерировать код для каждого оператора возврата:

void foo (int i, int j) {
  A a;
  if (i > 0) {
     B b;
     return ;   // Call dtor for 'b' followed by 'a'
  }
  if (i == j) {
     C c;
     B b;
     return ;   // Call dtor for 'b', 'c' and then 'a'
  }
  return 'a'    // Call dtor for 'a'
}

, Если размер кода является проблемой - тогда, это может быть чем-то стоящим избежать.

другая проблема касается "Названный Возвращаемым значением OptimiZation" (иначе Копия Elision, C++ ISO '03 12.8/15). C++ позволяет реализации пропускать вызов конструктора копии, если это может:

A foo () {
  A a1;
  // do something
  return a1;
}

void bar () {
  A a2 ( foo() );
}

Просто взятие кода, как, объект 'a1' создается в 'нечто', и затем его конструкцию копии назовут для построения 'a2'. Однако копия elision позволяет компилятору создавать 'a1' в том же месте на стеке как 'a2'. Нет поэтому никакой потребности "скопировать" объект, когда функция возвращается.

Несколько точек выхода усложняют работу компилятора в попытке обнаружить это, и по крайней мере для относительно последней версии VC ++, оптимизация не произошла, где тело функции имело несколько возвратов. См. Названный Оптимизацией Возвращаемого значения в Visual C++ 2005 для получения дополнительной информации.

Существуют хорошие вещи сказать о наличии единственной точки выхода, так же, как существуют плохие вещи сказать о неизбежности "стрелка" программирование, которое заканчивается.

При использовании нескольких точек выхода во время контроля ввода или распределения ресурсов, я пытаюсь поместить все 'ошибочные выходы' очень явно во главе функции.

И спартанская статья Programming "SSDSLPedia" и единственная функциональная точка выхода статья "Портлендского Репозитория Шаблона Wiki" имеют некоторые проницательные аргументы вокруг этого. Кроме того, конечно, существует это сообщение для рассмотрения.

, Если Вы действительно хотите единственную точку выхода (на каком-либо non-exception-enabled языке), например, для высвобождения средств в одном единственном месте, я нахожу тщательное применение goto, чтобы быть хорошим; посмотрите, например, этот скорее изобретенный пример (сжатый для сохранения экранного агента по операциям с недвижимостью):

int f(int y) {
    int value = -1;
    void *data = NULL;

    if (y < 0)
        goto clean;

    if ((data = malloc(123)) == NULL)
        goto clean;

    /* More code */

    value = 1;
clean:
   free(data);
   return value;
}

Лично мне, в целом, не нравится стрелка, программируя больше, чем мне не нравятся несколько точек выхода, хотя оба полезны, когда применено правильно. Лучшее, конечно, должно структурировать Вашу программу для требования ни одного. Разрушение Вашей функции в несколько блоков обычно помогает:)

, Хотя при выполнении так, я нахожу, что заканчиваю с несколькими точками выхода так или иначе как в этом примере, где некоторая большая функция была разломана на несколько меньших функций:

int g(int y) {
  value = 0;

  if ((value = g0(y, value)) == -1)
    return -1;

  if ((value = g1(y, value)) == -1)
    return -1;

  return g2(y, value);
}

В зависимости от проекта или инструкций по кодированию, большая часть шаблонного кода могла быть заменена макросами. Как примечание стороны, повреждая его вниз этот путь делает функции g0, g1, g2 очень легкими протестировать индивидуально.

, Очевидно, в OO и поддерживающем исключение языке, я не использовал бы операторы "if" как этот (или вообще, если бы я мог бы выйти сухим из воды с мало достаточно усилия), и код был бы намного более простым. И нестреловидный. И большинство незаключительных возвратов, вероятно, было бы исключениями.

Короче говоря;

• Немного возвратов лучше, чем много возвратов
• , больше чем один возврат лучше, чем огромные стрелки, и , защитные пункты вообще в порядке.
• Исключения могли, вероятно, заменить большинство 'защитных пунктов, если это возможно.

Одно серьезное основание, о котором я могу думать, для обслуживания кода: у Вас есть единственная точка выхода. Если Вы хотите изменить формат результата..., просто намного более просто реализовать. Кроме того, для отладки можно просто засунуть точку останова там:)

Однако я когда-то должен был работать в библиотеке, где стандарты кодирования наложили 'один оператор возврата на функцию', и я нашел его довольно жестким. Я пишу много числового кода вычислений, и часто существуют 'особые случаи', таким образом, код закончил тем, что был довольно тверд следовать...

Несколько точек выхода хорошо для достаточно небольших функций - то есть, функция, которая может быть просмотрена на одной экранной длине на ее полноте. Если долгая функция аналогично включает несколько точек выхода, это - знак, что функция может быть нарублена далее.

, Который сказал, что я избегаю функций нескольких-выходов если абсолютно необходимый . Я чувствовал боль ошибок, которые происходят из-за некоторого случайного возврата в некоторой неясной строке в более комплексных функциях.

Я работал с ужасными стандартами кодирования, которые вызвали единственный путь выхода на Вас, и результатом являются почти всегда неструктурируемые спагетти, если функция совсем не тривиальна - Вы заканчиваете с большим количеством повреждений, и продолжается, это просто мешает.

Единственный важный вопрос, "Как код более прост, лучше читаем, легче понять?" Если это более просто с несколькими возвратами, затем используйте их.

В интересах хорошие стандарты и промышленные методы наиболее успешной практики , мы должны установить корректное количество операторов возврата для появления во всех функциях. Очевидно, существует согласие против наличия одного оператора возврата. Таким образом, я предлагаю, чтобы мы установили его в два.

я ценил бы его, если все просмотрят их код прямо сейчас, определят местоположение каких-либо функций только с одной точкой выхода и добавят другой. Это не имеет значения где.

результатом этого изменения, несомненно, будет меньше ошибок, большей удобочитаемости и невообразимого богатства, падающего с неба на наши головы.

Я предпочитаю единственный оператор возврата. Одна причина, на которую еще не указали, состоит в том, что некоторые инструменты рефакторинга работают лучше на единственные точки выхода, например, Eclipse, JDT извлекают/встраивают метод.

Вы должны никогда , используют оператор возврата в методе.

я знаю, что на меня вскочат для этого, но я серьезен.

Операторы возврата являются в основном похмельем со дней процедурного программирования. Они - форма goto, наряду с повреждением, продолжают, если, переключатель/случай, в то время как, поскольку, уступают и некоторые другие операторы и эквиваленты на большинстве современных языков программирования.

Операторы возврата эффективно 'GOTO' точка, где функция была вызвана, присвоив переменную в том объеме.

Операторы возврата - то, что я называю 'Удобным Кошмаром'. Они, кажется, добиваются цели быстро, но вызывают обширные головные боли обслуживания по линии.

Операторы возврата диаметрально настроены против Инкапсуляции

, Это - самое важное и фундаментальное понятие объектно-ориентированного программирования. Это - смысл существования ООП.

Каждый раз, когда Вы возвращаете что-либо из метода, Вы в основном 'пропускаете' информацию состояния от объекта. Не имеет значения, если Ваше состояние изменилось или нет, ни прибывает ли эта информация из других объектов - это не имеет никакого значения для вызывающей стороны. То, что это делает, позволяют поведению объекта быть за пределами объекта - повреждающаяся инкапсуляция. Это позволяет вызывающей стороне начинать управлять объектом способами, которые приводят к хрупким проектам.

ЛОД является Вашим другом

, я рекомендую любому разработчику читать о Закон (Лода) Demeter на c2.com или Википедии. ЛОД является принципами проектирования, которые использовались в местах, которые имеют реальные ограничения программного обеспечения 'для решения ответственных задач' в прямом смысле, как JPL. Это, как показывали, уменьшило сумму ошибок в коде и улучшило гибкость.

Там имеет превосходную аналогию на основе прогулки с собакой. При прогулке с собакой Вы физически не достаете ее участки и перемещаете их таким образом, что собака идет. Вы управляете, чтобы собака шла, и она заботится участки сами по себе. Оператор возврата на этой аналогии эквивалентен собаке, позволяющей Вам доставать ее участки.

Только говорят с Вашими непосредственными друзьями:

1. аргументы функции, Вы находитесь в,
2. Ваши собственные атрибуты,
3. любые объекты, которые Вы создали в функции

, Вы заметите, что ни один из них не требует оператора возврата. Вы могли бы думать, что конструктор является возвратом, и Вы идете к чему-то. На самом деле возврат от средства выделения памяти. Конструктор просто устанавливает то, что находится в памяти. Это в порядке, пока, инкапсуляция которого новый объект в порядке, потому что, когда Вы сделали его, Вы имеете полный контроль над ним - никто еще не может повредить его.

атрибуты Доступа других объектов является правильным. Методы get отсутствуют (но Вы знали, что они уже были плохи, правильно?). Методы set в порядке, но лучше использовать конструкторов. Наследование плохо - когда Вы наследовались другому классу, любые изменения в том классе могут и вероятно повреждать Вас. Сниффинг типа плох (Да - ЛОД подразумевает, что Java/C++, основанная на типе стиля отправка является неправильной - спрашивающий о типе, даже неявно, , повреждающаяся инкапсуляция. Тип является неявным атрибутом объекта. Интерфейсы являются Правильной Вещью).

Итак, почему это - весь проблема? Ну, если Ваша вселенная не очень отличается от моей, Вы тратите много кода отладки времени. Вы не пишете код, который Вы планируете на никогда повторное использование. Ваши требования к программному обеспечению изменяются, и это вызывает внутренние изменения API/интерфейса. Каждый раз, когда Вы использовали оператор возврата, Вы представили очень хитрую зависимость - методы, возвращая что-либо требуются, чтобы знать о том, как независимо от того, что они возвращаются, будет используемым - который является каждым случаем! Как только интерфейс изменяется на одном конце или другом, все может повредиться, и Вы сталкиваетесь с долгим и утомительным поиском на ошибку.

Они действительно - рак в Вашем коде, потому что, как только Вы начинаете использовать их, они способствуют дальнейшему использованию в другом месте (который является, почему можно часто находить цепочки метода возврата среди объектных систем).

Поэтому, какова альтернатива?

Говорят , не спрашивать.

С ООП - цель состоит в том, чтобы сказать другие объекты, что сделать, и позволить им заботиться о нем. Таким образом, необходимо забыть процедурные способы сделать вещи. Это легко действительно - просто никогда не пишут операторы возврата. Существуют намного лучшие способы сделать то же самое:

нет ничего неправильно с возвратом понятие , но возвратитесь , операторы глубоко испорчены.

, Если Вам действительно нужен ответ назад - используют вызов назад. Передача в структуре данных, чтобы быть заполненным в, даже. Тем путем Вы содержите интерфейсы в чистоте и открытый для изменения, и Ваша целая система менее хрупка и более адаптируема. Это не замедляет Вашу систему, на самом деле это может ускорить его, таким же образом как оптимизация последнего вызова делает - кроме этого случая, нет никакого последнего вызова, таким образом, Вы не должны даже напрасно тратить время, управляя стеком с возвращаемыми значениями.

, Если Вы следуете за этими аргументами, Вы найдете там, действительно никогда потребность в операторе возврата.

, Если Вы применяете эти методы, я гарантирую, что довольно скоро Вы найдете расходы ошибок поиска намного меньшего количества времени адаптируются к изменениям требования намного более быстро, и имеющий меньше проблем, понимая собственный код.