Что такое магические числа в коде — объясняем на пальцах
Если ты когда-либо открывал чужой код и видел там нечто вроде `if (score > 42)` или `for (int i = 0; i < 360; i += 15)`, то знай — ты столкнулся с магическими числами. Это такие числовые значения, которые появляются в коде без объяснения, почему они выбраны именно такими. Они вроде бы работают, но вызывают кучу вопросов: почему 42? почему шаг 15? что за 360? Хороший код должен быть читаемым не только для твоего сегодняшнего "я", но и для команды, которая будет поддерживать проект через полгода. Магические числа в программировании делают этот процесс сложнее, потому что не несут никакой контекстной информации.
Почему избегать магических чисел — не просто совет, а необходимость
Представь: ты работаешь над системой расчёта зарплат, и у тебя в коде есть строка `if (bonus > 5000)`. Через три месяца выясняется, что бонусный порог изменился. Весь отдел лихорадочно ищет эту пятитысячную цифру по коду, чтобы её заменить. Был бы это именованный константный параметр вроде `BONUS_THRESHOLD = 5000`, всё бы решилось за 10 секунд.
Вот основные причины, по которым стоит избегать магических чисел:
- Они затрудняют понимание логики программы.
- Изменения требуют ручного поиска по всему коду.
- Ошибки легко пропустить при копировании кода.
- Они мешают масштабированию и повторному использованию функций.
Типичный пример магических чисел в коде
Возьмём простой пример из фронтенд-разработки:
```javascript
function calculateOpacity(scrollPosition) {
if (scrollPosition < 100) {
return 0.5;
} else if (scrollPosition < 300) {
return 0.8;
} else {
return 1;
}
}
```
Ни одно из этих чисел не объяснено. Почему именно 100 и 300? Почему не 120 или 280? При доработке дизайна разработчику придётся разбираться, откуда ноги растут. Лучше сделать так:
```javascript
const FADE_START = 100;
const FADE_END = 300;
function calculateOpacity(scrollPosition) {
if (scrollPosition < FADE_START) {
return 0.5;
} else if (scrollPosition < FADE_END) {
return 0.8;
} else {
return 1;
}
}
```
Теперь всё ясно. Даже если ты не писал этот код, тебе не нужно гадать, откуда взялись эти значения.
Как заменить магические числа: практический подход
Чтобы избавиться от магических чисел, надо просто сделать их частью контекста кода. Вот как это делается на практике:
- Заводи именованные константы. Вместо `30` используй `MAX_LOGIN_ATTEMPTS = 30`. Это сразу объясняет значение числа.
- Используй перечисления (enum), если числа связаны с состояниями. Например, статус заказа может быть `0 = NEW`, `1 = PROCESSING`, `2 = SHIPPED`.
- Группируй связанные значения в структуры или объекты. Это особенно удобно в языках с объектной моделью.
- Даже в однострочных функциях не ленись дать значением имена. Это не "лишняя работа", а инвестиция в поддержку проекта.
Проблемы с магическими числами: кейсы из реальной практики
Кейс 1: Сломанный отчёт из-за "непонятной пятёрки"
В одном проекте для банка в расчётах использовалось условие `if (interestRate > 5)`. Долгое время это работало, пока регулятор не изменил минимальный порог ставки. Разработчики искали "пятёрку" по всему коду, но она повторялась в десятках мест. Исправление заняло три дня. Был бы параметр `MIN_INTEREST_RATE`, всё решилось бы одной строкой.
Кейс 2: Неудачный рефакторинг мобильного приложения
В другом проекте, связанном с геолокацией, использовалось `if (distance < 1000)`. Никто не знал, что 1000 — это лимит в метрах до ближайшей точки интереса. После рефакторинга число заменили на 800, думая, что это просто пример. В итоге приложение стало показывать неверные рекомендации, и пришлось выкатывать фикс в экстренном порядке. Если бы использовалась константа вроде `MAX_POI_DISTANCE`, ошибок можно было бы избежать.
Вывод: магия должна быть понятной
Магические числа — это не просто "плохой стиль". Это мина замедленного действия. Они делают код непрозрачным, сложным в доработке и уязвимым к ошибкам. Особенно это критично в командной разработке и при долгосрочной поддержке.
Если хочешь писать чистый, масштабируемый и дружелюбный код — избавляйся от магических чисел. Используй говорящие названия, описывай контекст, и тогда твой код будут читать с удовольствием, а не с болью.
Помни: хороший код — это не тот, который работает, а тот, который понятен.
