Как лучше писать if условия?

Question

[Shrei]

Допустим, у меня есть функция/метод который возвращает булевое значение. Сперва идет проверка условий, а потом уже какая-то логика. Как лучше описывать?

Вариант 1:

if(foo == bar && foo >= 1) {
  //Логика
  return true;
}

return false;

Вариант 2:

if(foo != bar) return false;
if(foo < 1) return false;
//Логика
return true;

Answer 1

[Sanan Yuzb]

Лучше писать так:
return (foo == bar && foo >= 1) ? true : false;

Comments

[Shrei]

Этот вариант не плох если у вас функция однострочная, но когда логика чуть раздутие кроме головной боли у меня ничего не вызывает

[Армянское Радио]

return foo == bar && foo >= 1 тогда уж, Зачем еще тернарный оператор?

[Сергей Протько]

Sanan Yuzb лучше так НЕ писать.

return foo == bar && $foo >= 1;

Да и вообще по возможности тернарных операторов нужно избегать.

[Даниил Игоревич]

Сергей Протько: это почему?

[Сергей Протько]

Даниил Ораин: результат операции и так булево значение. А тернарный оператор ухудшает читабельность кода. Использовать его нужно довольно редко.

[Владимир Проскурин]

Даниил Ораин: нарушают читабельность кода.

Answer 2

[Армянское Радио]

Второе лучше, потому как в первом { можно { получить { миллиард { уровней { вложенности } } } } }

Comments

[Михаил Усоцкий]

Лучше избегать слишком глубоких вложенностей с условиями. Процессор такое не одобрит. Лучше делать грамотный алгоритм.

[Армянское Радио]

Михаил Усоцкий: Преждевременная оптимизация - корень всех зол. Предположение о том, во что компилятор превратит исходник, работало 1995 году, когда компилятор был безмозглым. Сейчас этого делать не стоит.

[Михаил Усоцкий]

Армянское Радио: это не является преждевременной оптимизацией. Условные переходы всегда являлись для процессора с конвейером тяжёлой задачей, тем более миллиард. А уж на графических процессорах - и вовсе критической. Поэтому такие глубокие вложенности - не есть хорошо.

[Армянское Радио]

Михаил Усоцкий: если вы внимательно прочтете мой ответ, я как раз советую не использовать много уровней вложений.

[kalterfive]

Михаил Усоцкий: на самом деле нормально, компилятор оптимизирует.

[Михаил Усоцкий]

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

Answer 3

[mitaichik]

1. Согласен с тем что выходить нужно как можно быстрее. Поэтому лучше как-то так:

if(foo != bar || foo < 1) {
  return false;
}
// логика
return true;

2. Деление условий должно быть осмысленно с точки зрения бизнес-логики. Если условие foo != bar || foo < 1 является целостным и неделимым с точки зрения бизнес логики, то лучше его не делить.

Если же это 2 разных условия (две разных ситуции), просто скомпонованных в одно условие, то вполне допустимо их разделить для логического выделения (опять таки с точки зрения бизнес-логики). Например, если foo - кол-во товаров в заказе, a bar - кол-во товаров при котором дается скидка (не больше не меньше):

// кол-во товара в корзине != кол-ву товара при котором делается скидка 
if(foo != bar){
    return false;
}

// если корзина вообще пуста
if(foo < 1){
  return false
}

// применение скидки к заказу

return true;

Answer 4

[Rou1997]

Если допустим, то обоими, и плюс еще несколькими.

Answer 5

[private_tm]

Вариант 1 конечно. Читаемость прежде всего. По производительности по моему тоже если первая проверка не пройдет второй уже не будет проверятся.

Comments

[Армянское Радио]

Разницы по производительности в данном примере нет. Условия по стандарту вычисляются слева направо. Если в длинной конъюнкции встречается false, вычисления заканчиваются и продолжение не обрабатывается.

Answer 6

[Сергей Протько]

if (!(foo == bar && foo >= 1)) return false;

подход называется "ранний выход", и призван он улучшить читабельность.

Comments

[Алексей Уколов]

Никогда с первого раза не могу прочитать такие условия. Иногда, когда условий 2-3, строю такие конструкции, проверяю их где-нибудь, а потом стираю и разбиваю на несколько проверок.

[Сергей Протько]

Алексей Уколов: ну можно было бы написать так:

if (foo !== bar || foo < 1) return false;

Answer 7

[mamkaololosha]

Вы должны завершить работу функции так рано, как это возможно. Дальше может быть создание больших и сложных объектов, а потом фигак и параметр null, а вы уже насоздавали всего ненужного.

Answer 8

[d'Ivan]

Можно ещё используя Short-circuit evaluation:

res = true
res &&= (foo == bar)
res &&= (foo != baz)
if (res) some_logic1
res &&= (foo >= 1)
if (res) some_logic2
return res

Преимущество кода в том, что проверки идут друг за другом, линейно, а не вложенно.
В отличие от, скажем, такого кода:

res = false
if (foo == bar && foo != baz) {
  some_logic1
  if (foo >= 1) {
    some_logic2;
    res = true
  }
}
return res

Дополнительно,
имеется способ описания бизнес логики при помощи таблицы принятия решений, берущей свои корни где-то примерно с 50-60-х прошлого века.

Comments

[jcmvbkbc]

> res &&= (foo == bar)
> res &&= (foo != baz)

Оператора &&= нет в С/С++ и, полагаю, в большинстве остальных языков.

[d'Ivan]

jcmvbkbc: в Си синтаксис другой, я взял с языка Руби.
Но суть ведь не в синтаксисе. Можно записать и res = res && (foo == bar)

Answer 9

[SolidMinus]

Вариант 1, конечно! Во втором даже ; нет

Answer 10

[Василий Мельников]

Лучше не писать return в условии вообще, один return в конце функции.
А условия объединять стоит если они логически объединены общим смыслом. Т..е. их потенциально можно вынести в отдельную функцию.
Написано только что

Answer 11

[Alexander]

Сперва лучше писать "нормальное" прохождение условия (т.е. то, когда алгоритм идёт по "ожидаемому/приемлемому" сценарию). А потом уже делать ответвления на "отклонения от нормы".
Конечно же, данный совет не всегда применим :)

Answer 12

[oleg_1956]

Лучше с чьей точки зрения?
Если человека, то Вам тут уже много понаписали.
Я программирую контроллеры, там другой подход и другое понимание "лучше" - в сомнительных случаях пишу несколько вариантов и смотрю ассемблерный код. Именно его (так себе это можно представить, несколько упрощая реальность) и будет выполнять CPU.
Да, есть еще и точка зрения оптимизирующего компилятора. Его точка зрения как раз и выражается в ассемблерном коде.
Как правило, "скучный и плоский" лучше оптимизируется - keep it simple, stupid. :)

Comments

[Дмитрий]

А что называете "скучным и плоским"? Можете пример?

[oleg_1956]

"скучным и плоским"?
Как пример (мое личное восприятие) - разбиение условного оператора с несколькими условиями на несколько условных операторов с одним условием. Этот прием делает текст кода (в реальной жизни) плохо воспринимаемым, внешне похожим на восстановленный код при реверсинжиниринге. Но, при разумно организованной последовательности вложенности, позволяет сэкономить машинные такты. Не память.
Можно было бы (и нужно?) привести показательный пример "прогибания" под компилятор, но это будет не совсем по теме обсуждения.

[oleg_1956]

хотя....
все определяется компилятором
хороший (в моем понимании) будет выполнять сложное условие последовательно (ну, с учетом порядка действия), т.е., сам разобьет несколько условий на цепочку одинарных.
не хороший - посчитает результат ВСЕГО условия (т.е., поступит как мы написали)
но не хороших, наверное, уже не осталось, но я их еще застал :))) и привык "прогибаться" под компилятор - KISS-принцип