Если операторы в функции, каков лучший способ

Я предпочитаю первый вариант - быстро сбой чище, понятнее, легче читать и понимать.

Я понимаю, что это не сбой, а концепция по-прежнему применяется. Мне вообще не нравятся вложенные операторы if .

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

public void function(string value, string value2)
{
    if (string.IsNullOrEmpty(value1)) throw new ArgumentNullException("value1", "value 1 was not set");
    if (string.IsNullOrEmpty(value2)) throw new ArgumentNullException("value2", "value 2 was not set");

    DoSomething();
}

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

// leave complex conditional code out, so that we can focus on the larger problem in the function
public void function(string value, string value2)
{
    if (MyDescriptiveTestName)
    {
        DoSomething();
    }
}

// encapsulate complex conditional code so that we can focus solely on it.
private bool MyDescriptiveTestName(string value, string value2)
{
    if (value != null && value2 == value)
    {
        return true;
    }
    return false;
}

Если у вас есть функция с большим количеством условий, я бы использовал оператор switch , а не ifs. Я также могу разбить детали на несколько функций (или даже классов), если это возможно.

Связанные статьи о переполнении стека :

• i s «else if» быстрее, чем «switch () case»?
• Когда использовать If-else if-else вместо состояний switch и наоборот

Могу я порекомендовать книгу Чистый код Роберта К. Мартина, которая предоставляет отличный набор эвристик для написания удобочитаемого и поддерживаемого кода.

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

public void function(string value, string value2)
{
    if (valuesAreValidAndEqual(value, value2))
    {
        DoSomething();
    }
}

private void valuesAreValidAndEqual(string value, string value2)
{
    return value != null && value2 == value;
}

Очевидно, это более полезно, если имена переменных и имена функций связаны с вашим доменом.

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

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

Нет ЛУЧШЕГО способа размещения операторов if, я думаю, ответы субъективны.

Тот факт, что вы заранее думаете о читабельности кода, - это полдела.

Что касается того, какой из ваших примеров наиболее читабелен, это довольно субъективно.

Мои мысли по поводу приведенных примеров:

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

Я предпочитаю второй вариант. Лично, когда я читаю подобный код, я имею в виду условия, при которых я бы перешел на каждый вложенный уровень. В первом примере я бы, вероятно, забыл, что первое условие (значение == null равно false) продолжает выполняться. Третий тоже неплохой, но я предпочитаю второй.

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

Вот мои личные практические правила при создании функции с множеством условных проверок:

1. Группируйте условия в логические единицы, когда это возможно.
2. Используйте четко названные промежуточные значения для упрощения чтения и отладки.
3. Избегайте повторения одних и тех же логических конструкций более одного раза (см. Выше).
4. Если возможно, выполните рефакторинг комплекса или дорогостоящие условия в отдельные функции.
5. Когда возможно, используйте условия раннего выхода в верхней части метода для выхода, но ...
6. Избегайте повторения операторов возврата по всему телу метода.
7. Не полагайтесь на в отношении приоритета операторов используйте круглые скобки для группировки операторов.
8. Не полагайтесь на отступы, используйте блоки ({...}) даже с одним оператором, это поможет с ремонтопригодностью.