Поток управления через Возврат по сравнению с, Если/Еще [закрыто]

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

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

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

Тем не менее, я предпочитаю это:

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

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

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

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

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

Я бы предпочел тот, который я определяю как тот, который ВЫПОЛНЯЕТ меньше кода.
Если для class.Editable чаще встречается значение false, я бы выбрал A.

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

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

РЕДАКТИРОВАТЬ:
Для пояснения:
Под меньшим количеством выполняемого кода я на самом деле подразумеваю наиболее эффективный ...

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

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

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

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

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

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

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

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

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

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

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