Инвертируйте оператор if, чтобы уменьшить вложенность

Это просто спорное. По вопросу досрочного возврата «соглашения между программистами» нет. Насколько я знаю, это всегда субъективно.

Можно привести аргумент о производительности, поскольку лучше иметь записанные условия, которые чаще всего выполняются; можно также утверждать, что это яснее. С другой стороны, он создает вложенные тесты.

Не думаю, что вы получите однозначный ответ на этот вопрос.

Это вопрос мнения.

Мой нормальный подход - избегать однострочных ifs и возвратов в середине метода.

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

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

Основная причина уменьшения вложенности - улучшение читаемость кода и ремонтопригодность. Помните, что многим другим разработчикам потребуется читать ваш код в будущем, а код с меньшим отступом, как правило, читать намного легче.

Предварительные условия - отличный пример того, где можно вернуться в начале функции. Почему на удобочитаемость остальной части функции должно влиять наличие проверки предварительного условия?

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

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

Плохая читабельность кода будет.

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

Это, конечно, субъективно, но я думаю, что это сильно улучшает два момента:

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

Защитные предложения или предварительные условия (как вы, вероятно, видите) проверяют, выполняется ли определенное условие, а затем прерывают выполнение программы. Они отлично подходят для мест, где вас действительно интересует только один результат заявления if. Так что вместо того, чтобы говорить:

if (something) {
    // a lot of indented code
}

Вы меняете условие и прерываете его, если это обратное условие выполняется.

if (!something) return false; // or another value to show your other code the function did not execute

// all the code from before, save a lot of tabs

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

Вы увидите лучшие примеры того, как это можно применить во вложенных условиях:

if (something) {
    do-something();
    if (something-else) {
        do-another-thing();
    } else {
        do-something-else();
    }
}

против:

if (!something) return;
do-something();

if (!something-else) return do-something-else();
do-another-thing();

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

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

Я считаю, что возврат «в середине функции» не должен быть таким «субъективным». Причина довольно проста, возьмите этот код:

    function do_something( data ){

      if (!is_valid_data( data )) 
            return false;


       do_something_that_take_an_hour( data );

       istance = new object_with_very_painful_constructor( data );

          if ( istance is not valid ) {
               error_message( );
                return ;

          }
       connect_to_database ( );
       get_some_other_data( );
       return;
    }

Может быть, первое «возвращение» не НАСТОЛЬКО интуитивно понятно, но это действительно экономия. Слишком много «идей» о чистых кодах, которым просто нужно больше практики, чтобы избавиться от «субъективных» плохих идей.

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

double getPayAmount() {
    double result;
    if (_isDead) result = deadAmount();
    else {
        if (_isSeparated) result = separatedAmount();
        else {
            if (_isRetired) result = retiredAmount();
            else result = normalPayAmount();
        };
    }
     return result;
};

В этом случае, если _isDead верен, мы можем сразу выйти из метода. Возможно, лучше было бы структурировать его так:

double getPayAmount() {
    if (_isDead)      return deadAmount();
    if (_isSeparated) return separatedAmount();
    if (_isRetired)   return retiredAmount();

    return normalPayAmount();
};   

Я выбрал этот код из каталог рефакторинга. Этот конкретный рефакторинг называется: Заменить вложенные условные предложения на защитные предложения.

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

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

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

Множественные точки возврата были проблемой в C (и, в меньшей степени, C++), потому что они заставляли вас дублировать код очистки перед каждой из точек возврата. Со сборкой мусора try | Конструкция finally и блоки using, на самом деле нет причин, по которым вам стоит их бояться.

В конечном итоге все сводится к тому, что вам и вашим коллегам легче читать.

Здесь есть несколько хороших моментов, но есть и несколько точек возврата может быть нечитаемым, если метод очень длинный. При этом, если вы собираетесь использовать несколько точек возврата, просто убедитесь, что ваш метод короткий, иначе бонус читабельности в виде нескольких точек возврата может быть потерян.

У такого типа кодирования есть несколько преимуществ, но для меня большой выигрыш в том, что если вы сможете быстро вернуться, вы сможете улучшить скорость своего приложения. Т.е. я знаю, что благодаря Предварительному условию X я могу быстро вернуться с ошибкой. Это сначала избавляет от ошибок и снижает сложность вашего кода. Во многих случаях, поскольку конвейер процессора теперь может быть чище, он может остановить сбои конвейера или переключение. Во-вторых, если вы зациклились, быстрое отключение или выход из строя может сэкономить вам много процессора. Некоторые программисты используют инварианты цикла для такого рода быстрого выхода, но в этом случае вы можете сломать конвейер процессора и даже создать проблему поиска в памяти, что означает, что процессор должен загружаться из внешнего кеша. Но в основном я думаю, что вы должны делать то, что планировали, а именно завершать цикл или функцию, а не создавать сложный путь кода, просто чтобы реализовать какое-то абстрактное понятие правильного кода. Если единственный инструмент, который у вас есть, - это молоток, то все будет похоже на гвоздь.

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

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

Много веских причин о как выглядит код. А как насчет полученные результаты?

Давайте посмотрим на код C# и его скомпилированную форму IL:

using System;

public class Test {
    public static void Main(string[] args) {
        if (args.Length == 0) return;
        if ((args.Length+2)/3 == 5) return;
        Console.WriteLine("hey!!!");
    }
}

Этот простой фрагмент можно скомпилировать. Вы можете открыть сгенерированный файл .exe с помощью ildasm и проверить результат. Я не буду выкладывать все, что касается ассемблера, но опишу результаты.

Сгенерированный код IL выполняет следующие действия:

1. Если первое условие - false, переходит к коду, где находится второе.
2. Если это true, то переходит к последней инструкции. (Примечание: последняя инструкция - возврат).
3. Во втором условии то же самое происходит после вычисления результата. Сравните и: дошли до Console.WriteLine, если это false, или до конца, если это true.
4. Распечатайте сообщение и вернитесь.

Так что вроде код перескочит до конца. Что, если мы сделаем нормальный if с вложенным кодом?

using System;

public class Test {
    public static void Main(string[] args) {
        if (args.Length != 0 && (args.Length+2)/3 != 5) 
        {
            Console.WriteLine("hey!!!");
        }
    }
}

В инструкциях IL результаты очень похожи. Разница в том, что раньше было два перехода на каждое условие: если false перейти к следующему фрагменту кода, если true перейти к концу. И теперь код IL течет лучше и имеет 3 перехода (компилятор немного оптимизировал это):

1. Первый переход: когда длина равна 0, к части, где код снова перескакивает (Третий переход) до конца.
2. Второе: в середине второго условия, чтобы избежать одной инструкции.
3. Третье: если второе условие - false, переходите до конца.

В любом случае счетчик программ всегда будет прыгать.

Лично я предпочитаю только одну точку выхода. Этого легко достичь, если вы будете использовать короткие и точные методы, и это обеспечит предсказуемый шаблон для следующего человека, который будет работать над вашим кодом.

например.

 bool PerformDefaultOperation()
 {
      bool succeeded = false;

      DataStructure defaultParameters;
      if ((defaultParameters = this.GetApplicationDefaults()) != null)
      {
           succeeded = this.DoSomething(defaultParameters);
      }

      return succeeded;
 }

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

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

Я обнаружил, что мой код действительно нечитаем при написании хост-приложения ASIO с помощью ASIOSDK Steinberg, поскольку я следовал парадигме вложенности. Он прошел примерно на восемь уровней, и я не вижу здесь недостатка дизайна, как упоминал Эндрю Баллок выше. Конечно, я мог бы упаковать некоторый внутренний код в другую функцию, а затем вложить туда оставшиеся уровни, чтобы сделать его более читабельным, но мне это кажется довольно случайным.

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

Так что это может быть другая ситуация, когда инвертированные if могут способствовать более ясному коду.

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

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

Лично я согласен с ReSharper и первой группой (на языке, в котором есть исключения, я считаю глупым обсуждать «множественные точки выхода»; почти все может бросить вызов, поэтому существует множество потенциальных точек выхода во всех методах).

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

Это не только влияет на эстетику, но также предотвращает вложение кода.

Фактически это может служить предварительным условием для проверки достоверности ваших данных.

С точки зрения производительности заметной разницы между двумя подходами не будет.

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

Существуют конкурирующие школы мысли относительно того, какой подход предпочтительнее.

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

Другая точка зрения, с точки зрения более функционального стиля, заключается в том, что метод должен иметь только одну точку выхода. Все в функциональном языке - это выражение. Таким образом, операторы if всегда должны иметь предложения else. В противном случае выражение if не всегда имело бы значение. Так что в функциональном стиле первый подход более естественен.

Спектакль состоит из двух частей. У вас есть производительность, когда программное обеспечение находится в производстве, но вы также хотите иметь производительность при разработке и отладке. Меньше всего разработчику хочется «ждать» чего-то тривиального. В конце концов, компиляция этого с включенной оптимизацией приведет к аналогичному коду. Так что хорошо знать эти маленькие уловки, которые окупаются в обоих сценариях.

Дело в вопросе ясное, ReSharper прав. Вместо того, чтобы вкладывать операторы if и создавать новую область видимости в коде, вы устанавливаете четкое правило в начале своего метода. Это увеличивает удобочитаемость, его будет легче поддерживать, и он сокращает количество правил, которые нужно просеивать, чтобы найти, куда они хотят пойти.

Как отмечали другие, снижения производительности не должно быть, но есть и другие соображения. Помимо этих обоснованных опасений, в некоторых обстоятельствах это также может привести к ошибкам. Предположим, вы вместо этого имеете дело с double:

public void myfunction(double exampleParam){
    if (exampleParam > 0){
        //Body will *not* be executed if Double.IsNan(exampleParam)
    }
}

Сравните это с эквивалентной инверсией по-видимому:

public void myfunction(double exampleParam){
    if (exampleParam <= 0)
        return;
    //Body *will* be executed if Double.IsNan(exampleParam)
}

Так что при определенных обстоятельствах то, что кажется правильно перевернутым if, может не быть.

Я хотел бы добавить, что есть название для этих перевернутых if - Guard Clause. Я использую его, когда могу.

Я ненавижу читать код там, где в начале есть два экрана кода и ничего больше. Просто переверните if и вернитесь. Так никто не будет тратить время на прокрутку.

http://c2.com/cgi/wiki?GuardClause

Избегание нескольких точек выхода может приводит к увеличению производительности. Я не уверен насчет C#, но в C++ оптимизация именованного возвращаемого значения (Copy Elision, ISO C++ '03 12.8 / 15) зависит от наличия единственной точки выхода. Эта оптимизация позволяет избежать копирования, создавая ваше возвращаемое значение (в вашем конкретном примере это не имеет значения). Это может привести к значительному увеличению производительности в узких циклах, поскольку вы сохраняете конструктор и деструктор при каждом вызове функции.

Но в 99% случаев сохранение дополнительных вызовов конструктора и деструктора не стоит потери читаемости вложенных блоков if (как указывали другие).

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

Подробнее о предсказании ветвлений здесь.

Не уверен, но думаю, что R # старается избегать дальних прыжков. Когда у вас есть IF-ELSE, компилятор делает что-то вроде этого:

Условие false -> дальний переход к false_condition_label

true_condition_label: инструкция1 ... инструкция_n

false_condition_label: инструкция1 ... инструкция_n

конец блока

Если условие истинно, перехода и развертывания кэша L1 нет, но переход к метке false_condition_label может быть очень далеким, и процессор должен развернуть свой собственный кеш. Синхронизация кеша стоит дорого. R # пытается заменить дальние переходы на короткие, и в этом случае с большей вероятностью все инструкции уже находятся в кеше.