Это - плохая практика для использования возврата в пустом методе?

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

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

Рассмотрим:

void MyFunc(object obj)
{
    if (obj != null)
    {
        obj.DoSomething();
    }
}

по сравнению с:

void MyFunc(object obj)
{
    if (obj == null)
        return;

    obj.DoSomething();
}

Сейчас, представьте, что другой программист добавляет строку: obj.DoSomethingElse ();

void MyFunc(object obj)
{
    if (obj != null)
    {
        obj.DoSomething();
    }

    obj.DoSomethingElse();
}

void MyFunc(object obj)
{
    if (obj == null)
        return;

    obj.DoSomething();
    obj.DoSomethingElse();
}

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

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

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

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

Плохая практика ??? Ни за что. Фактически, всегда лучше обрабатывать проверки, возвращаясь из метода как можно раньше, если проверки не пройдут. В противном случае это привело бы к огромному количеству вложенных ifs & elses. Раннее завершение улучшает читаемость кода.

Также проверьте ответы на аналогичный вопрос: Следует ли использовать оператор return / continue вместо if-else?

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

В первом примере используется защита заявление. Из Википедии :

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

Я думаю, что наличие группы охранников в верхней части метода - это совершенно понятный способ программирования. По сути, он говорит: «Не выполняйте этот метод, если что-либо из этого верно».

В общем, он хотел бы следующего:

void DoThis()
{
  if (guard1) return;
  if (guard2) return;
  ...
  if (guardN) return;

  DoThat();
}

Я думаю, что это намного более читабельно, чем:

void DoThis()
{
  if (guard1 && guard2 && guard3)
  {
    DoThat();
  }
}

Нет снижения производительности, однако второй фрагмент кода более читабелен и, следовательно, проще в обслуживании.

Это нормально и без «потери производительности», но никогда не пишите оператор if без скобок.

Всегда

if( foo ){
    return;
}

Это намного удобнее; и вы никогда случайно не предположите, что некоторые части кода находятся внутри этого оператора, хотя это не так.

В этом случае ваш второй пример - лучший код, но он не имеет ничего общего с возвратом из функции void, это просто потому, что второй код более прямой. Но возврат из функции void - это нормально.

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

Использование return в середине метода, пустого или другого, является очень плохой практикой по причинам, которые были довольно четко сформулированный почти сорок лет назад покойным Эдсгером В. Дейкстрой, начиная с хорошо известного «Заявление GOTO, признанное вредным» и продолжая в «Структурированном программировании» Даля, Дейкстры и Хора.

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

Также стоит упомянуть, что Никлаус Вирт изменил семантику оператора RETURN в Oberon-07, последней версии языка программирования Oberon, сделав его завершающей частью объявления типизированной процедуры (то есть функции), а не исполняемый оператор в теле функции. В его объяснении изменения сказано, что он сделал это именно потому, что предыдущая форма БЫЛА нарушением принципа одного выхода структурного программирования.