Управление потоком через возврат против If/Else

Ответ 1

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

Ответ 2

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

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

Ответ 3

Я предпочитаю второй подход для удобства чтения и обслуживания. Читаемость, потому что она просто читает "чище" для меня, чем первый подход, и ремонтопригодность, потому что мне не нужно беспокоиться о добавлении фигурных скобок, если мне нужно изменить предложения if или else. Кроме того, первый подход на 7 символов меньше, чем второй, если вы не включаете новые строки, что вряд ли представляется оправданием для выбора первого за второй.

Тем не менее, я действительно предпочитаю это:

public ActionResult Edit(MyClass class)
{
    ActionResult rv = null;
    if (class.Editable)
    {
        class.Update();
        rv = View();
    }
    return rv;
}

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

Ответ 4

Оба этих оператора управляют потоком через оператор if. Это просто вопрос, как вы справляетесь с этим условием.

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

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

Ответ 5

Я бы предпочел тот, который я идентифицирую как тот, который ВЫИГРАЛ меньше кода.
Если это более распространено для класса. Возможно, это false, я бы пошел на A.

Но этот пример не дает большого преимущества в обоих случаях.

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

EDIT:
Чтобы уточнить:
Выполнение меньше кода, который я на самом деле означает, является наиболее эффективным...

Ответ 6

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

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

Ответ 7

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

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

Является ли ActionResult перечислением или базовым классом? Если это перечисление, почему вы возвращаете null, когда Edit возвращает то, что представляется переименованием? Разве не было бы чище просто вернуть значение ActionResult, которое указывает, что никаких действий не было предпринято, потому что объект не был в редактируемом состоянии?

Ответ 8

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

Это действительно довольно известная школа мысли среди толпы Code Contracts.

Ответ 9

Первый вариант, используя возврат, лучше, потому что:

• у вас есть место, где можно поставить всех охранников и предусловий, рядом с вашими утверждениями и всем этим.
• для меня легче думать: "Посмотрите все, что может быть неправильно, и вернитесь. С этого момента у меня есть все, что мне нужно, и я нахожусь на Счастливый путь
• если вы используете подход if/else, у вас есть весь код в этом отступе метода/функции. Добавьте другое, если, или для, и все начнет забавляться.

Один из инициаторов этого метода (return) - Маркус Зарра, в Cocoa это стиль моей подруги по кодированию

Ответ 10

Я предпочитаю первый вариант, если проверяемый случай является защитой/предварительным условием, которое должно выполняться для того, чтобы вызов метода был действительным. Хотя вы можете утверждать, что вы должны вернуть значение null или выбросить (Argument) Exception. Когда класс не редактируется, должен ли он быть параметром для этого метода?

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

Ответ 11

Я тоже предпочитаю if/else. Разборчивость, удобочитаемость и ремонтопригодность выше всего для меня.

Ответ 12

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