Чи слід повертатися з функції рано чи використовувати оператор 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, де потрібно очистити вручну, багато чого можна сказати для повернення в одну точку. Навіть якщо зараз немає необхідності щось чистити, хтось може відредагувати вашу функцію, виділити щось і потрібно очистити її перед поверненням. Якщо це станеться, це буде робота кошмару, яка буде переглядати всі заяви про повернення.

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

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

C # Напевно я не можу відповісти.

D-мова дає вам належну вбудовану охорону для виходу з області застосування і тому добре підготовлений до раннього виходу, тому не повинен представляти іншого питання, крім стилю.

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

Раннє повернення за виграш. Вони можуть здаватися потворними, але набагато менш потворними, ніж великі ifобгортки, особливо якщо є кілька умов для перевірки.

Я використовую і те, і інше.

Якщо DoSomethingце 3-5 рядків коду, тоді код просто виглядає красиво за допомогою першого методу форматування.

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

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

По-іншому, простіше міркувати про те, коли ваше програмне забезпечення вийде з розпорядку, якщо у вас є лише 1 повернення. Що також є аргументом проти винятків.

Зазвичай я мінімізую підхід щодо раннього повернення.

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

Це залежить.

Дострокове повернення, якщо є явна умова тупикового зв'язку, щоб перевірити його негайно, що призведе до безглуздість роботи решти функції. *

Встановіть Retval + одиночне повернення, якщо функція є більш складною і може в іншому випадку мати декілька точок виходу (проблема читабельності).

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

Використовуйте If

У книзі Дон Кнут про «GOTO's» я прочитав його, і він наводив причину того, що він завжди мав найімовірніший стан у першому випадку. За припущенням, що це все-таки розумна ідея (і не з чистого врахування швидкості епохи). Я б сказав, що раннє повернення не є хорошою практикою програмування, особливо враховуючи той факт, що вони частіше за все не використовуються для обробки помилок, якщо тільки ваш код швидше виходить з ладу, ніж не виходить з ладу :-)

Якщо ви будете дотримуватися наведених вище порад, вам потрібно буде поставити це повернення в нижній частині функції, і тоді ви можете навіть не називати його поверненням туди, просто встановіть код помилки і поверніть його два рядки. Тим самим досягається ідеал 1 вихід 1 вихід.

Специфічні для Delphi ...

Я маю на увазі, що це хороша практика програмування для програмістів 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" може збільшити накладні витрати (я забув цитату про 3-рівневі відступи).

Я вважаю за краще тримати, якщо заяви невеликі.

Отже, вибираючи між:

if condition:
   line1
   line2
    ...
   line-n

і

if not condition: return

line1
line2
 ...
line-n

Я вибрав би те, що ви описали як "раннє повернення".

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

Вкладені, якщо і для, і поки страшні , уникайте їх будь-якою ціною.

Як кажуть інші, це залежить. Для невеликих функцій, які повертають значення, я можу кодувати раннє повернення. Але для значних функцій мені подобається завжди мати місце в коді, де я знаю, що можу помістити те, що буде виконано до повернення.

Я практикую невдачу на рівні функцій. Він тримає код послідовним та чистим (як для мене, так і для тих, з ким я працював). Через це я завжди повертаюся рано.

Для деяких часто перевірених умов ви можете реалізувати аспекти цих перевірок, якщо ви використовуєте AOP.