Використовуйте інше після винятку (або ні)

Розглянемо цей біт коду:

if (x == 1)
{
  throw "no good; aborting" ;
}

[... more code ...]

Тепер розглянемо цей код:

if (x == 1)
{
  throw "no good; aborting" ;
}
else
{
  [... more code ...]
}

Два випадки працюють абсолютно однаково. Перший випадок має ту перевагу, що вам не доведеться "обробляти" решту коду в else. Друга перевага полягає в тому, щоб дотримуватися практики явного використання elseдля кожного if.

Чи може хтось надати якісь тверді аргументи на користь одного над іншим?

Не слід додавати elseпісля ifгілок, які беззастережно порушують керування потоком , наприклад, ті, що містять a throwабо a return. Це дозволило б покращити читабельність вашої програми, видаливши зайвий рівень вкладення, запроваджений elseфілією.

Те, що виглядає більш-менш ОК із синглом, throwстає по-справжньому некрасивим, коли кілька кидків поспіль отримують пошкодження:

void myMethod(int arg1, int arg2, int arg3) {
    // This is demonstrably ugly - do not code like that!
    if (!isValid(arg1)) {
        throw new ArgumentException("arg1 is invalid");
    } else {
        if (!isValid(arg2)) {
            throw new ArgumentException("arg2 is invalid");
        } else {
            if (!isValid(arg3)) {
                throw new ArgumentException("arg3 is invalid");
            } else {
                // The useful code starts here
            }
        }
    }
}

Цей фрагмент робить те саме, але виглядає набагато краще:

void myMethod(int arg1, int arg2, int arg3) {
    if (!isValid(arg1)) {
        throw new ArgumentException("arg1 is invalid");
    }
    if (!isValid(arg2)) {
        throw new ArgumentException("arg2 is invalid");
    }
    if (!isValid(arg3)) {
        throw new ArgumentException("arg3 is invalid");
    }
    // The useful code starts here
}

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

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

Скажіть, наприклад, у вас є ця функція:

public void ConfigureOblogon(Oblogon oblogonToConfigure)
{
    if (_validColors.Contains(oblogonToConfigure.Color))
    {
        oblogonToConfigure.ColorIndex = _validColors.IndexOf(oblogonToConfigure.Color);
    }
    else
    {
        oblogonToConfigure.Color = _validColors[0];
        oblogonToConfigure.ColorIndex = 0;
    }
}

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

public void ConfigureOblogon(Oblogon oblogonToConfigure)
{
    if (!_validOblogons.Contains(oblogonToConfigure.Type))
    {
        oblogonToConfigure.Type = _validOblogons[0];
        oblogonToConfigure.TypeIndex = 0;
        if (_validColors.Contains(oblogonToConfigure.Color))
        {
            oblogonToConfigure.ColorIndex = _validColors.IndexOf(oblogonToConfigure.Color);
        }
        else
        {
            oblogonToConfigure.Color = _validColors[0];
            oblogonToConfigure.ColorIndex = 0;
        }
    }
    else
    {
        oblogonToConfigure.TypeIndex = _validOblogons.IndexOf(oblogonToConfigure.Type);
    }
}

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

public void ConfigureOblogon(Oblogon oblogonToConfigure)
{
    if (!_validColors.Contains(oblogonToConfigure.Color))
    {
        oblogonToConfigure.Color = _validColors[0];
    }

    oblogonToConfigure.ColorIndex = _validColors.IndexOf(oblogonToConfigure.Color);
}

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

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

SomeFunction()
{
    if (isvalid)
    {
        /* ENTIRE FUNCTION */
    }
    /* Nothing should go here but something does on accident, and an invalid scenario is created. */
}

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

SomeFunction()
{
    if (!isvalid)
    {
        /* Nothing should go here, and it's so small no one will likely accidentally put something here */
        return;
    }

    /* ENTIRE FUNCTION */
}