@Shrei

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

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

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

return false;

Вариант 2:
if(foo != bar) return false;
if(foo < 1) return false;
//Логика
return true;
  • Вопрос задан
  • 867 просмотров
Пригласить эксперта
Ответы на вопрос 12
Sanan07
@Sanan07
Писатель-прозаик
Лучше писать так:
return (foo == bar && foo >= 1) ? true : false;
Ответ написан
gbg
@gbg
Баянист. Тамада. Услуги.
Второе лучше, потому как в первом { можно { получить { миллиард { уровней { вложенности } } } } }
Ответ написан
mitaichik
@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;
Ответ написан
Rou1997
@Rou1997
Если допустим, то обоими, и плюс еще несколькими.
Ответ написан
@private_tm
JAVA dev
Вариант 1 конечно. Читаемость прежде всего. По производительности по моему тоже если первая проверка не пройдет второй уже не будет проверятся.
Ответ написан
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
if (!(foo == bar && foo >= 1)) return false;

подход называется "ранний выход", и призван он улучшить читабельность.
Ответ написан
@mamkaololosha
Вы должны завершить работу функции так рано, как это возможно. Дальше может быть создание больших и сложных объектов, а потом фигак и параметр null, а вы уже насоздавали всего ненужного.
Ответ написан
2ord
@2ord
продвинутый чайник
Можно ещё используя 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-х прошлого века.
Ответ написан
BacCM
@BacCM
C++ почти с рождения
Лучше не писать return в условии вообще, один return в конце функции.
А условия объединять стоит если они логически объединены общим смыслом. Т..е. их потенциально можно вынести в отдельную функцию.
Написано только что
Ответ написан
AlexRaptor
@AlexRaptor
Сперва лучше писать "нормальное" прохождение условия (т.е. то, когда алгоритм идёт по "ожидаемому/приемлемому" сценарию). А потом уже делать ответвления на "отклонения от нормы".
Конечно же, данный совет не всегда применим :)
Ответ написан
@oleg_1956
Лучше с чьей точки зрения?
Если человека, то Вам тут уже много понаписали.
Я программирую контроллеры, там другой подход и другое понимание "лучше" - в сомнительных случаях пишу несколько вариантов и смотрю ассемблерный код. Именно его (так себе это можно представить, несколько упрощая реальность) и будет выполнять CPU.
Да, есть еще и точка зрения оптимизирующего компилятора. Его точка зрения как раз и выражается в ассемблерном коде.
Как правило, "скучный и плоский" лучше оптимизируется - keep it simple, stupid. :)
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы