Должен ли я вернуться из функции раньше или использовать оператор if? [закрыто]

Я часто писал такого рода функции в обоих форматах, и мне было интересно, если один формат предпочтительнее другого и почему.

public void SomeFunction(bool someCondition)
{
    if (someCondition)
    {
        // Do Something
    }
}

или же

public void SomeFunction(bool someCondition)
{
    if (!someCondition)
        return;

    // Do Something
}

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

Я предпочитаю второй стиль. Сначала удалите недопустимые случаи, либо просто выйдите, либо вызвав исключения в зависимости от ситуации, вставьте пустую строку, затем добавьте «реальное» тело метода. Мне легче читать.

Определенно последнее. Первый не выглядит плохо сейчас, но когда вы получаете более сложный код, я не могу себе представить, что кто-то подумает так:

public int SomeFunction(bool cond1, string name, int value, AuthInfo perms)
{
    int retval = SUCCESS;
    if (someCondition)
    {
        if (name != null && name != "")
        {
            if (value != 0)
            {
                if (perms.allow(name)
                {
                    // Do Something
                }
                else
                {
                    reval = PERM_DENY;
                }
            }
            else
            {
                retval = BAD_VALUE;
            }
        }
        else
        {
            retval = BAD_NAME;
        }
    }
    else
    {
        retval = BAD_COND;
    }
    return retval;
}

более читабельно, чем

public int SomeFunction(bool cond1, string name, int value, AuthInfo perms)
{
    if (!someCondition)
        return BAD_COND;

    if (name == null || name == "")
        return BAD_NAME;

    if (value == 0)
        return BAD_VALUE;

    if (!perms.allow(name))
        return PERM_DENY;

    // Do something
    return SUCCESS;
}

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

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

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

public int myFunction(string parameterOne, string parameterTwo) {
  // Can't work without a value
  if (string.IsNullOrEmpty(parameterOne)) {
    throw new ArgumentNullException("parameterOne");
  } 
  if (string.IsNullOrEmpty(parameterTwo)) {
    throw new ArgumentNullException("parameterTwo");
  }

  // ...      
  // Do some work
  // ...

  return value;
}

Я предпочитаю раннее возвращение.

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

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

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

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

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

C # Я, конечно, не могу ответить на.

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

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

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

Я использую оба.

Если DoSomething3-5 строк кода, то код выглядит красиво, используя первый метод форматирования.

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

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

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

Обычно я минимизирую подход с ранним возвратом.

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

По-разному.

Ранний возврат, если есть некоторое очевидное тупиковое условие, которое нужно проверить сразу, что сделает бессмысленным запуск остальной части функции. *

Установите Retval + single return, если функция более сложна и может иметь несколько точек выхода в противном случае (проблема читабельности).

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

Используйте If

В книге Дона Кнута о GOTO я читал, как он объясняет причину, по которой наиболее вероятное условие стоит первым в утверждении if. При условии, что это все еще разумная идея (а не исключение из соображений скорости эпохи). Я бы сказал, что ранние возвраты не являются хорошей практикой программирования, особенно если учесть тот факт, что они чаще всего используются для обработки ошибок, если ваш код с большей вероятностью не сработает, чем не сработает :-)

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

Delphi Specific ...

Я считаю, что это хорошая практика программирования для программистов на Delphi, хотя у меня нет никаких доказательств. Pre-D2009, мы не имеем атомный способ вернуть значение, у нас есть exit;и result := foo;или мы могли бы просто выбросить исключение.

Если бы вам пришлось заменить

if (true) {
 return foo;
} 

за

if true then 
begin
  result := foo; 
  exit; 
end;

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

if false then 
begin
  result := bar;

   ... 
end
else
   result := foo;

и просто избегать exitвообще.

Я согласен со следующим утверждением:

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

Взято из этого вопроса в stackoverflow .

Я использую ранний возврат почти исключительно в эти дни, до крайности. Я пишу это

self = [super init];

if (self != nil)
{
    // your code here
}

return self;

как

self = [super init];
if (!self)
    return;

// your code here

return self;

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

Я бы предпочел написать:

if(someCondition)
{
    SomeFunction();
}

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

Мне не нравится, как обработка ошибок удалена от проверки.

if not error A
  if not error B
    if not error C
      // do something
    else handle error C
  else handle error B
else handle error A

Я предпочитаю это:

if error A
  handle error A; return
if error B
  handle error B; return
if error C
  handle error C; return

// do something

Условия наверху называются «предварительными условиями». Ставя if(!precond) return;, вы визуально перечисляете все предпосылки.

Использование большого блока if-else может увеличить накладные расходы на отступ (я забыл цитату о трехуровневых отступах).

Я предпочитаю сохранить, если заявления небольшие.

Итак, выбирая между:

if condition:
   line1
   line2
    ...
   line-n

а также

if not condition: return

line1
line2
 ...
line-n

Я бы выбрал то, что вы описали как «раннее возвращение».

Имейте в виду, я не забочусь о досрочном возврате или о чем-то другом, я просто очень хотел бы упростить код, сократить тела операторов if и т. Д.

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

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

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

Для некоторых часто проверяемых условий вы можете реализовать аспекты для этих проверок, если используете AOP.