Инвертирование, “если” оператор для сокращения вложения

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

, например,

 bool PerformDefaultOperation()
 {
      bool succeeded = false;

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

      return succeeded;
 }

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

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

Пункты охраны или предварительные условия (как можно, вероятно, видеть) проверка, чтобы видеть, соблюдено ли определенное условие и затем повреждает поток программы. Они являются великими для мест, где Вы действительно только интересуетесь одним результатом 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();

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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