Операторы if else

Операторы if else

Технический фундамент условий

Перед любой прикладной логикой важно понимать, как if работает на уровне языка: условие сначала приводится к булевому значению (true или false), и только потом выбирается ветка.

Базовые правила:

  • в if (...) можно передать не только boolean, но и любое выражение;
  • JavaScript неявно приводит результат к boolean;
  • поэтому важно знать truthy/falsy значения и явно проверять типы, когда это критично.
function classifyValue(value) {
  if (value) return 'truthy';
  return 'falsy';
}

Пример показывает механику языка: 0, '', null, undefined, NaN, false попадут в falsy, а остальные значения - в truthy.

Смотри, что важно: проверка if (value) иногда слишком грубая для прикладной логики. Например, 0 и пустая строка могут быть валидными значениями, но они falsy.

function getPageLabel(page) {
  // page = 0 — валидная страница, но if(page) будет false
  if (page === 0) return 'first page';
  if (typeof page === 'number') return 'some page';
  return 'unknown';
}

Почему if/else это основа прикладной логики

Почти любой сценарий в продукте - это развилка: показать экран или ошибку, пустить дальше или заблокировать, применить скидку или нет. if/else как раз и описывает такие решения в коде.

Ключевой момент: if запускает код при истинном условии, else описывает альтернативу.

Проверь себя: почему неправильная проверка в одном if может изменить весь пользовательский сценарий?

Базовый синтаксис

const score = 72;

if (score >= 70) {
  console.log('passed');
} else {
  console.log('retry');
}

Здесь условие score >= 70 возвращает true или false, и от этого зависит, какой блок выполнится.

Смотри, что важно: фигурные скобки лучше использовать всегда, даже для одной строки.

Цепочки else if

Когда вариантов больше двух, добавляют else if.

function getLevel(score) {
  if (score >= 90) return 'excellent';
  else if (score >= 70) return 'good';
  else if (score >= 50) return 'basic';
  return 'retry';
}

Порядок проверок критичен: более строгие условия должны идти раньше.

Здесь часто путаются: если сначала проверить score >= 50, то ветка >= 90 уже не достигнется.

Проверь себя: что вернет функция при score = 95, если поменять порядок проверок местами?

Вложенные условия

Иногда нужно учитывать несколько уровней правил.

if (isAuth) {
  if (hasSubscription) {
    console.log('full access');
  } else {
    console.log('limited access');
  }
} else {
  console.log('auth required');
}

Вложенность работает, но при большой глубине код становится тяжелым для чтения.

Анти-провал: если вложенность растет, выноси проверки в отдельные булевы переменные или функции.

Еще один прием для читаемости: guard clauses (ранние возвраты). Они позволяют быстро "отсечь" негативные кейсы и не растить вложенность.

function getAccessState2(isAuth, hasSubscription) {
  if (!isAuth) return 'auth required';
  if (!hasSubscription) return 'limited access';
  return 'full access';
}

Мини-сценарий: доступ к уроку

function getAccessState(isBlocked, isAuth, isPublished) {
  if (isBlocked) return 'blocked';
  if (!isAuth) return 'auth-required';
  if (!isPublished) return 'draft';
  return 'open';
}

Это реальный паттерн: приоритет условий отражает бизнес-логику.

Смотри, что важно: "блокировка" стоит первой, потому что она сильнее остальных флагов.

Частые ошибки новичков

  • Путать = и === в условии.
  • Нарушать порядок else if и получать неверный результат.
  • Перегружать один if слишком длинным выражением.
  • Не обрабатывать fallback-ветку (else).

Анти-провал: каждый if-блок должен отвечать на один четкий вопрос, а не на пять сразу.

Что будет, если изменить входные данные

В getAccessState:

  • isBlocked=true -> всегда blocked;
  • isBlocked=false, isAuth=false -> auth-required;
  • isAuth=true, isPublished=false -> draft;
  • все ok -> open.

Проверь себя: почему полезно тестировать именно такие крайние комбинации флагов?

Краткий итог

  • if/else управляет ветвлением и бизнес-решениями в приложении.
  • Для нескольких вариантов используют else if с правильным приоритетом.
  • Читаемость и порядок условий важнее "короткости" записи.
  • Вложенные условия допустимы, но их нужно контролировать.
  • Надежные условия строятся на явных проверках и покрытии edge case.