Возможный дубликат:
Должно & lsquo; else & rsquo; храниться или отбрасываться в тех случаях, когда он не нужен?
При
a = 0
Это:
var foo = function() {
if (a != 0) return true
return false
}
Или это:
var bar = function() {
if (a != 0) return true
else return false
}
Во всяком случае, во время компиляции он оптимизируется, поэтому нет разницы во времени.
Как обычно, вы можете спорить о стиле. Мои 50 центов: первый вариант (без явно выраженного) более приятный, потому что он меньше делает код точно так же.
Конечно, в этом случае вы бы сделали
return a != 0;
... но я думаю, что этот вопрос должен быть общим.
Вы должны делать все, что делает код более понятным.
Я бы сказал, что это хорошая практика, потому что это немного изменило бы код. Например, скажем, вы хотели распечатать результат. Вы можете либо изменить его так:
if (a != 0) {
print "returning true"
return true
}
print "returning false"
return false
Это означает добавление печати дважды, иначе:
if (a != 0) {
retval = true
} else {
retval = false
}
print "returning ", retval
return retval
что означает добавление одной печати, но это не будет работать без else.
Конечно, это надуманный пример, но он показывает, как следует пытаться сделать ваш код максимально удобным для обслуживания.
Поскольку компилятор, вероятно, уменьшит его до одного и того же скомпилированного кода, сделайте то, что считаете более "красивым".
Обратите внимание, что элегантность кода субъективна, поэтому догматически цепляться за тот или иной формат не требуется.
if(statement)
result = true
else
result = false
return result
Оба будут работать одинаково на большинстве языков, но я думаю, что использование else было бы лучше сделать более очевидным, что, когда ни одно из приведенных выше инструкций if/else if не является истинным, сделайте это, хотя это, очевидно, не является необходимым.
Но, однако, если у вас есть много кода ниже инструкции if, тогда вы не должны этого делать, поскольку это только станет огромным беспорядком с множеством ненужных инструкций else.
Если язык требует скобок для операторов if/else, мне лично нравится удалить инструкцию else и прилагаемые фигурные скобки. Намерение кода будет таким же четким, но код будет меньше отступов, что (обычно) улучшает читаемость.
Как уже упоминалось, компилятор оптимизирует оператор else. Но если вы имеете дело с интерпретируемым языком, оператор else должен интерпретироваться. В этом случае его удаление приведет к незначительному (очень незначительному) увеличению производительности.
Конечно, "else" должно быть явно объявлено.
Существует несколько причин, по которым "else" должно быть объявлено явно:
По концептуальной причине выше, она, конечно же, зависит от вашей спецификации функции. Для некоторой функции имеет смысл использовать такой код. Например, "Функция предполагает, что посетитель не зарегистрирован, он зарегистрирован только в том случае, если bla-bla-bla".
Но для другой проблемы, например: "Если число делится на два, то это даже нечетно", вы должны написать его явно, чтобы читатель (возможно, не программист) не путался при чтении кода. Поскольку читатель (может быть, математик) знает только такой инвариант, он мало знает о языке программирования.
Я бы не хотел использовать else, если он лишний, любой разработчик должен понять, что произойдет:
public void DoSomethingConditionally(Foo foo)
{
if (Bar)
{
foo.DoX();
return;
}
foo.DoY();
}
Я не согласен с людьми, которые хотят только одну точку возврата на каждую функцию, ваши функции должны быть небольшими, а несколько точек возврата улучшаться, а не препятствовать читаемости.
Просто придерживайтесь другого и переходите к чему-то более интересному!
IMO. Если ваше намерение состоит в возврате true, когда выполняется какое-либо условие (например, что-то найдено), а затем, возможно, обрабатывать данные другим способом, и, наконец, когда ничего не найдено, верните false, параметр без else яснее.
Если ваше возвращаемое значение зависит только от условия в if, вариант if-else выглядит лучше.
Это не имеет значения. Компилятор будет иметь одинаковый код в любом случае. Проверьте, как выглядит существующий код, а затем просто сделайте то же самое.
Лично я не помещаю "else", потому что это очевидно. Я нахожу, что лишний "else" выглядит загроможденным.
Мне лично нравится синтаксис:
/*Function header comments*/
Function(...)
{
/*English what the if is trying to achieve*/
If(...)
{
...
Return True; /*What this tells me*/
}
Else
{
...
Return False: /*What this tells me*/
}
}
Просто потому, что я нахожусь в ситуации, если я просто делаю
If(...)
Return True;
Else
Return False;
или
If(...)
Return True;
Return False;
или
(...)?Return True:Return False;
Это не так ясно, хотя с правильным комментарием один лайнер классный, и если я все-таки делаю сравнение, есть хороший шанс, что по дороге я могу подумать о чем-то, что должно произойти в этом в любом случае, я имею в виду, что я делаю, если больше, чем усмешки. Также, если я нахожу специальный случай, который нуждается в Else If, это просто вопрос добавления частей Else If.
function DoSomethingConditionally(foo)
{
if (Bar)
{
foo.DoX();
return;
}
else
{
foo.DoY();
}
}
Мне нравится этот стиль, на всякий случай мне нужно добавить что-то позже.
Мое решение использовать или не использовать "else" зависит от моей семантической интерпретации "if" и, в некоторых случаях, возвращаемого значения. В тех случаях, когда я чувствую, что "если" решает между двумя курсами действия или двумя возвращаемыми значениями, я буду использовать "else". В тех случаях, когда я чувствую, что он решает между тем, чтобы действовать нормально и "прервать раньше", я пропущу другое. В тех случаях, когда возвращаемое значение отвечает на вопрос "Что-то не удалось", я обычно буду рассматривать сообщение об ошибке как раннее прерывание, даже если единственное, что нужно сделать, это успех возврата и, таким образом, пропустить "else". Если, однако, возвращаемое значение спрашивает: "Это что-то ххх", то я гораздо чаще буду включать "else".
Пример слишком упрощен. Большинство ответов посвящено короткому сокращению кодирования, которое уклоняется от истинного вопроса о логических ветвях. Компилятор может оптимизировать ветку else так, чтобы он был логически эквивалентен не использованию ветки else, но зачем заставить компилятор работать больше? Если это язык сценариев, который часто компилируется, нет причин добавлять дополнительные "else".
Кроме того, анализаторы исходного кода не будут оптимизировать это. Дополнительное "else" будет считаться еще одной логической ветвью. Это может сделать ваши функции более "сложными", чем они есть. См. "Индекс CRAP", "Cyclomatic Complexity" и другие показатели программного обеспечения.
http://en.wikipedia.org/wiki/Cyclomatic_complexity
Если оба из следующих примеров получат компилятор, оптимизированный для одного и того же байтового кода, выберите подходящий вам стиль и придерживайтесь его. Лично я считаю, что первый пример более удобен в обслуживании.
public void DoSomethingConditionally(Foo foo)
{
if (Bar)
{
foo.DoX();
return;
}
if (Baz)
{
foo.DoZ();
return;
}
foo.DoY();
}
public void DoSomethingConditionally(Foo foo)
{
if (Bar)
{
foo.DoX();
}
elseif (Baz)
{
foo.DoZ();
}
else
{
foo.DoY();
}
return;
}
Стандарты кодирования LLVM и Стиль кодирования Mozilla оба состояния, которые иначе нельзя использовать после возврата.
В этом случае сразу верните результат выражения.
return (a != 0)
Но в целом я стараюсь избегать возврата из середины функции. Имейте один возврат за каждую функцию.