Лучше ли обернуть код в оператор "IF", или лучше "коротко замыкать" функцию и возвращать?
Я делаю кодировку в JavaScript, и у меня много случаев, когда я должен проверить некоторые вещи, прежде чем продолжить. У меня появилась привычка возвращаться на ранней стадии функции, но я не уверен, что я делаю это правильно. Я не уверен, влияет ли это на сложность моего кода, когда он растет.
Я хочу знать более опытные JavaScript-кодеры, что является лучшей общей практикой из следующих двух примеров. Или это не имеет значения, и они оба подходят для написания этого конкретного блока IF?
1) Возвращение раннего или "короткого замыкания", как я его называю (Оговорка о защите).
ServeAlcohol = function(age)
{
if(age < 19)
return;
//...Code here for serving alcohol.....
}
.. Или...
2) Заверните код в оператор IF.
ServeAlcohol = function(age)
{
if(age >= 19)
{
//...Code here for serving alcohol.....
}
}
Ответы
Ответ 1
Обычно у меня есть подтверждение ввода-подтверждения. Представьте себе, что если у вас есть куча условностей, вы сразу получите беспорядок вложенных if
.
Как правило, после получения проверки ввода я избегаю нескольких возвратов, но для проверки я возвращаюсь сразу. Держит его чище ИМХО.
Ответ 2
Я предпочитаю первую, потому что это условие охраны, и вы выходите напрямую. Но я не думаю, что есть проблемы с производительностью, просто, что это ваши предпочтения... Оба вернут выполнение напрямую...
Ответ 3
Личный выбор. Для меня, если есть некоторые условия "остановки", которые я могу проверить в начале метода, я предпочитаю использовать шаблон "return". Но только если я могу сделать все это в начале метода.
Ответ 4
FWIW, я предложу противоположное мнение. Структурированное программирование предполагает, что функция должна иметь одну точку выхода. Я думаю, что есть некоторые оптимизации компилятора, которые недоступны, если вы используете ранние отчеты о возврате, break, инструкции goto и т.п. Кроме того, большее количество веток в вашем коде означает, что его сложнее заполнить конвейер процессора, что приведет к возможному снижению производительности... Есть также причины не возвращаться рано, когда речь идет о строгих (то есть алгебраических) рассуждениях о правильности.
статья wiki структурированного программирования
Ответ 5
Это действительно зависит. Мне нравится одна точка возврата для простых функций, но что-то длиннее 10-20 строк, и я начну ломать дело ради ясности кода.
Ответ 6
Я предпочитаю первую, потому что это процесс устранения, когда вы возвращаетесь из функции до того, как программа даже должна пройти следующий раунд логики.
Я называю его prereq check
, где функция не будет выполняться, если она не соответствует prereq check
На самом деле, я делаю это все время, например, классический, где у меня есть функция, ожидающая целое число, и я получаю строку, я проверяю в верхней части функции, если она целое, НЕ, если это не строка или не другой объект/тип, что просто глупо в моей книге.
Это как приложение в колледже в Гарвард, предпосылка:
'I don't want to even want you to come for an interview if you don't have a 3.5GPA or higher!'
: =)
Ответ 7
Первый обычно предпочитается просто потому, что он уменьшает необходимый отступ (который может выйти из-под контроля). Нет реальной разницы в производительности.
Ответ 8
Есть люди, которые думают, что каждая функция должна иметь одну точку выхода. Тем не менее, я нахожу это более ясным, когда быстрые условные проверки, подобные тому, который вы упомянули, выполняются в начале. Это также предотвращает ненужный запуск кода.
Ответ 9
Общее правило, которое я слышал, в основном проваливается раньше и часто не работает. Вы никогда не знаете, когда одна строка кода указывает на какой-то суперперегруженный сеттер, который работает намного труднее, чем вы думаете. Если вы можете предотвратить выполнение этой строки кода - скажем, возвращаясь раньше - тогда ваш код будет экспоненциально более эффективным.
Другими словами, если вы можете вернуться раньше и не выполнять код, выполняйте его на каждом шагу, особенно если вы вообще не уверены в производительности. Возможно, это не так важно в чем-то вроде JS, я полагаю, что я больше парень AS3, но применяется одна и та же логика.
Если у вас много дел, лучше всего проследить точку отказа в каждом из них - в вашем примере проследите, чтобы это вернулось раньше, потому что возраст был слишком низким. Это поможет другим разработчикам, которые входят в систему и пытаются отладить ваш код, они будут знать, где что-то не удается и почему.
Надеюсь, что это поможет!:)
Ответ 10
В качестве альтернативы, поскольку JavaScript скрывает схему
HandleRequestForAlcohol = function(age) {
( IsUnderAge(age) ? RespondUnderAge : ServeAlcohol )();
}
Идиома для выбора функции не так важна, скорее, если вы выполняете сложную проверку, а затем выполняете несколько процессов, заставляйте их отделять функции, а не делать одну большую, если только она не находится в критическом критическом состоянии код.
Ответ 11
На мой взгляд, как лучшая практика, я думаю, что более важно последовательно использовать фигурные скобки с вашими блоками управления, даже если их тело - только одна строка.
В соответствии
if ( condition ) {
statement;
statement;
}
if ( condition ) {
statement;
}
Не согласовано
if ( condition ) {
statement;
statement;
}
if ( condition )
statement;
Но все же это совершенно субъективно.
Что касается того, когда выходить из функции и уровней отступов, это тоже субъективно. Исследования и опыт показали, что выход из функции только в одной точке (конец) легче отлаживать, оптимизировать и т.д. С другой стороны, несколько уровней отступов могут затруднить чтение функции.
Ответ 12
Если есть несколько/сложных охранников, я бы использовал возврат. В противном случае в случае одного простого условия (в маленькой функции), я предпочитаю использовать if.