Строгий режим и базовые ошибки новичков

Строгий режим и базовые ошибки новичков

Технический фундамент strict-дисциплины

'use strict' делает поведение языка менее двусмысленным:

• запрещает часть опасных "молчаливых" сценариев;
• превращает скрытые проблемы в явные ошибки;
• повышает предсказуемость работы переменных и контекста;
• лучше сочетается с современными практиками (const/let, строгие сравнения, линтеры).

Это не "дополнение", а базовый режим для надежного прикладного кода.

Зачем включать строгий режим

В обычном режиме JavaScript иногда "прощает" опасные вещи: неявные глобальные переменные, некоторые тихие преобразования, неочевидные ошибки в контексте this. Это может выглядеть удобно на старте, но в реальном проекте приводит к трудным багам. Строгий режим ('use strict') делает поведение языка более безопасным и предсказуемым.

Ключевой момент: strict mode помогает ловить ошибки раньше и делает код менее двусмысленным.

Проверь себя: почему "тихое исправление" движком иногда вреднее, чем явная ошибка?

Как включить strict mode

'use strict';

const score = 80;
console.log(score);

Строка 'use strict' должна быть в начале файла или функции.

Важно: в ES-модулях strict mode включен автоматически, но понимать правила все равно нужно.

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

Типичная ошибка №1: неявная глобальная переменная

'use strict';

function setMode() {
  mode = 'dark'; // ReferenceError
}

Без strict mode это могло случайно создать глобальную переменную mode. В строгом режиме ты сразу получаешь ошибку и исправляешь источник проблемы.

Анти-провал: всегда объявляй переменные явно через const или let.

Типичная ошибка №2: слабые сравнения

Новички часто используют ==, не учитывая приведение типов.

console.log(0 == false); // true
console.log('' == 0); // true

Без четкого понимания это приводит к ошибочным условиям. В прикладном коде чаще используй === и !==.

console.log(0 === false); // false

Смотри, что важно: strict mode не заменяет ===, но вместе с ним формирует более строгую дисциплину.

Типичная ошибка №3: работа с "грязным" вводом

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

'use strict';

const rawAge = '18';
const age = Number(rawAge);
const canAccess = age >= 18;

Если rawAge = 'abc', Number(rawAge) даст NaN, и условие начнет вести себя иначе, чем ожидаешь.

Правильнее сразу делать проверку на NaN:

const rawAge = '18';
const age = Number(rawAge);

if (Number.isNaN(age)) {
  console.log('invalid-age');
} else {
  console.log(age >= 18);
}

Проверь себя: почему проверка Number.isNaN(age) полезна перед сравнением?

Мини-сценарий: валидатор шага

Представь проверку перед переходом на следующий урок:

• есть авторизация (isAuth);
• возраст (age);
• заполненность email (hasEmail).

function validateStep(isAuth, age, hasEmail) {
  if (!isAuth) return 'auth-error';
  if (age < 18) return 'age-error';
  if (!hasEmail) return 'email-error';
  return 'ok';
}

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

Смотри, что важно: в этом примере предполагается, что age уже число, а hasEmail уже boolean (после нормализации ввода). В реальном приложении это почти всегда отдельный шаг перед валидацией.

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

• Забывать 'use strict' в учебных/простых скриптах.
• Писать == там, где нужен строгий контроль типов.
• Не нормализовать ввод (строки, пробелы, null).
• Смешивать много условий без явного приоритета.

Анти-провал: сначала приводи вход к ожидаемому типу, потом проверяй условия.

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

В validateStep:

• isAuth = false -> всегда auth-error;
• isAuth = true, age = 17 -> age-error;
• isAuth = true, age = 20, hasEmail = false -> email-error;
• все ок -> ok.

Такой явный сценарий проще тестировать и поддерживать.

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

Краткий итог

• Strict mode делает JavaScript более строгим и предсказуемым.
• Он помогает ловить опасные ошибки раньше (например, неявные глобальные переменные).
• Для сравнения значений в большинстве случаев лучше ===/!==.
• Нормализация и проверка входа обязательны в прикладных сценариях.
• Комбинация strict mode + явные проверки заметно снижает число новичковых багов.