Чи погана практика використовувати повернення всередині методу void?

Уявіть такий код:

void DoThis()
{
    if (!isValid) return;

    DoThat();
}

void DoThat() {
    Console.WriteLine("DoThat()");
}

Чи нормально використовувати повернення всередині методу void? Чи передбачено якесь покарання за продуктивність? Або було б краще написати такий код:

void DoThis()
{
    if (isValid)
    {
        DoThat();
    }
}

Повернення методу void непогано, це звичайна практика інвертування ifоператорів для зменшення вкладеності .

А менша кількість вкладеності у ваші методи покращує читабельність та ремонтопридатність коду.

Насправді, якщо у вас є метод void без будь-якого оператора return, компілятор завжди генерує інструкцію ret в кінці його.

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

Розглянемо:

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?

Це непогана практика (з усіх зазначених причин). Однак, чим більше повернень методу, тим більша ймовірність його поділу на менші логічні методи.

Перший приклад - використання інструкції гвардії. З Вікіпедії :

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

Я думаю, що наявність групи охоронців у верхній частині методу - це цілком зрозумілий спосіб програмування. По суті, це означає "не виконувати цей метод, якщо будь-який з них відповідає дійсності".

Тож загалом хотілося б такого:

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

  DoThat();
}

Я думаю, що це набагато читабельніше:

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

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

У цьому випадку ваш другий приклад - кращий код, але це не має нічого спільного з поверненням з функції void, це просто тому, що другий код є більш прямим. Але повернення з функції void цілком нормально.

Це цілком нормально і не вимагає „покарання за продуктивність”, але ніколи не пишіть заяву „якщо” без дужок.

Завжди

if( foo ){
    return;
}

Це набагато читабельніше; і ви ніколи випадково не припустите, що деякі частини коду знаходяться в цьому твердженні, коли їх немає.

Я збираюся не погодитися з усіма вашими, молодими шпигунами, щодо цього.

Використання повернення в середині методу, порожнього чи іншого, є дуже поганою практикою з причин, які були досить чітко сформульовані майже сорок років тому покійним Едджером В. Дейкстра, починаючи з добре відомого "Заяви ГОТО, що вважається шкідливою" ", і продовження у" Структурованому програмуванні "Даля, Дейкстри та Хоара.

Основне правило полягає в тому, що кожна структура управління та кожен модуль повинні мати рівно один вхід та один вихід. Явне повернення в середині модуля порушує це правило і значно ускладнює міркування про стан програми, що, в свою чергу, набагато важче сказати, правильна чи ні програма (що є набагато сильнішою властивістю ніж "чи працює це, чи ні").

"Заява GOTO вважається шкідливою" і "Структуроване програмування" започаткували революцію "Структурне програмування" 1970-х років. Ці дві частини є причинами, які ми маємо сьогодні - тоді - інакше, в той час як - робити, та іншими явними конструкціями управління сьогодні, і чому оператори GOTO мовами високого рівня є у списку зникаючих видів. (Моя особиста думка полягає в тому, що вони повинні бути у списку вимерлих видів.)

Варто зазначити, що модулятор потоку повідомлень, перший шматок військового програмного забезпечення, який коли-небудь пройшов тестування з першої спроби, без будь-яких відхилень, відмов або багатослів’я, написаний мовою, яка навіть не мала заява GOTO.

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

Використовуючи охорону, обов’язково дотримуйтесь певних вказівок, щоб не заплутати читачів.

• функція робить одне
• охоронці вводяться лише як перша логіка у функції
• безгнездная частина містить функцію в основному задумі

Приклад

// guards point you to the core intent
void Remove(RayCastResult rayHit){

  if(rayHit== RayCastResult.Empty)
    return
    ;
  rayHit.Collider.Parent.Remove();
}

// no guards needed: function split into multiple cases
int WonOrLostMoney(int flaw)=>
  flaw==0 ? 100 :
  flaw<10 ? 30 :
  flaw<20 ? 0 :
  -20
;

Викиньте виняток замість того, щоб нічого не повертати, коли об’єкт нульовий тощо.

Ваш метод очікує, що об'єкт не має значення null, і це не так, тому вам слід викинути виняток і дозволити абоненту обробляти це.

Але дострокове повернення - це не погана практика, інакше.