Лучше перенести код в оператор 'IF', или лучше 'сорвать' функцию и возврат? [закрытый]
Я делаю некоторое кодирование в JavaScript, и у меня есть много экземпляров, где я должен проверить некоторый материал, прежде чем я продолжу двигаться. Я выработал привычку возврата рано в функции, но я не уверен, делаю ли я это правильно. Я не уверен, оказывает ли это влияние на сложность моего кода, когда это растет.
Я хочу знать от более опытных кодеров JavaScript, что такое лучшая общая практика из следующего двум примерам. Или действительно ли это не важно, и они - оба хорошо способы записать этот конкретный ЕСЛИ блок?
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.....
}
}
12 ответов
Обычно у меня есть возвращение ввода-проверки сразу. Представьте, что если у вас был куча условных условий, вы получите беспорядок вложенного , если сразу.
Как правило, как только я получаю прошедшую проверку ввода, я избегаю нескольких возвратов, но для проверки я возвращаюсь сразу. Сохраняет его уборщиком ИМХО.
Я предпочитаю первый, потому что это процесс устранения, когда вы возвращаете из функции до того, как программа даже должна пройти через следующий раунд логики.
Я называю это моим Check PREREQ - где функция не будет выполнена, если она не соответствует чек Perreq
на самом деле, я делаю это все время, например, классический Одним из них есть, где у меня есть функция, которая ожидает целого числа, и я получаю строку, проверяю в верхней части функции, если это целое число, а не если это не строка или не другой объект / тип, это просто глупо в моей книге.
Это как приложение колледжа к Гарварду, предварительное условие:
«Я не хочу даже хотеть, чтобы вы пришли на собеседование, если у вас нет 3,5 Гпа или выше!»
: = )
Есть некоторые люди, которые думают, что каждая функция должна иметь одну точку выхода. Тем не менее, я считаю более понятнее, когда быстрые условные проверки, такие как тот, который вы упомянули, выполняются в начале. Это также избегает некоторого кода из ненужного запуска.
В качестве альтернативы, поскольку JavaScript является схемой в маскировке
HandleRequestForAlcohol = function(age) {
( IsUnderAge(age) ? RespondUnderAge : ServeAlcohol )();
}
IDIOM для выбора функции не так важно, скорее, если вы выполняете комплексную проверку, а затем иметь несколько процессов, фактор их Отдельные функции, а не создают один большой, если только он не является очень эффективным критическим битом кода.
Общее правило, которое я слышал, в основном не удается рано и часто провалился. Вы никогда не знаете, когда одна строка кода указывает на некоторую сверхперегруженную установку, который работает труднее, чем вы думаете. Если вы можете помешать выполнению этой строки кода - скажем, возвращаясь рано - тогда ваш код будет экспоненциально более эффективным.
Другими словами, если вы можете вернуться в раннее и сохранить код от выполнения, сделайте это на каждом ходу - особенно если вы вообще обеспокоены производительностью. Это может быть не так важно в чем-то вроде JS, я полагаю, я больше парень AS3 - но такая же логика применяется.
Если у вас есть много случаев, может быть наилучшим образом проследить точку отказа в каждом одном - в своем примере отслеживайте, что это возвращается рано, потому что возраст слишком низок. Это поможет другим разработчикам, которые вошли и пытаются отладить свой код, они будут знать, где вещи терпят неудачу и почему.
Надеюсь, что поможет! :)
Первый вариант обычно предпочтительнее просто потому, что он уменьшает необходимый отступ (который может выйти из-под контроля). Никакой реальной разницы в производительности нет.
FWIW, я предложу противоположное мнение. Структурированное программирование предполагает, что функция должна иметь одну точку выхода. Думаю, есть некоторые оптимизации компилятора, которые недоступны, если использовать ранние возвраты, операторы break, goto и тому подобное. Также большее количество ветвей в коде означает, что его труднее заполнить конвейером процессора, что приводит к возможному снижению производительности.... Есть также причины не возвращать ранние результаты, которые связаны со строгими (т.е. алгебрическими) рассуждениями о корректности.
, По-моему, как лучшая практика, я думаю, что более важно последовательно использовать фигурные скобки с вашими блоками управления, даже если их корпус является только одной строкой.
Последовательный
if ( condition ) {
statement;
statement;
}
if ( condition ) {
statement;
}
Не последовательный
if ( condition ) {
statement;
statement;
}
if ( condition )
statement;
, Но даже все еще, это абсолютно субъективно.
Что касается того, когда убежать из функции и уровней добавления отступа, это субъективно также. Исследование и опыт показали, что выход из функции только на один пункт (конец) легче отладить, оптимизировать, и т.д. С другой стороны, несколько уровней добавления отступа могут сделать функцию трудной читать.
Я предпочитаю первый, потому что это состояние охранника, и вы выходите напрямую. Но я не думаю, что есть проблемы с производительностью, только что это ваши предпочтения ... Оба вернутся непосредственно ...
Личный выбор. Для меня, если есть некоторые условия «остановки», которые я могу проверить в начале метода, я предпочитаю использовать шаблон «возврата». Но только если я могу сделать их все в начале метода.
Это действительно зависит. Мне нравится одна точка возвращения для простых функций, но все более длительное, чем 10-20 строк, и я начну разбите вещи ради кода.
Если есть несколько / сложных охранников, я бы использовал возврат. В противном случае в случае одного простого состояния (в маленькой функции), то я предпочитаю использовать, если.