JS. Сокращаем условия

Данная статья является переводом. Исходный материал.
Перевод выполнен каналом Frontend.Code

При написании кода важной частью являются условия, чаще всего мы используем их как "валидаторы", которые возвращают булевское значение, либо что-то на их основе. Затем, относительно этого значения выполняются новые инструкции.

Но большое количество длинных и запутанных инструкций if в коде вызывает путаницу у разработчиков и сильно понижает читаемость кода. Поэтому важно внедрять более эффективные условия.

Пример условного оператора

Представим, что мы создаем приложение для голосования. Каждый пользователь выбирает свой любимый цвет.

Очевидно, что у пользователей не так много вариантов, но давайте пока остановимся на простом решении.

Если пользователь проголосует за цвет, который не доступен для голосования? Может быть использовался выпадающий список, из которого мы забыли удалить некоторые цвета или список цветов прилетает с сервера, и там произошли какие-то изменения.

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

Круто! Теперь первое условие, которое проверяет функция, звучит так: "Разве цвет НЕ красный? Ну, это запрещено", и возвращает соответствующий результат.

А что если мы хотим принимать еще и синий цвет?

А если у нас много цветов? Напомню, что мы сейчас используем только условный оператор if

Код работает, но он длинный, беспорядочный и теперь практически нечитабельный.

Как исправить это с помощью массива

Для начала, определим массив с доступными цветами validColors:

Теперь можем использовать метод .includes() для проверки

В данном случае мы напишем:

Для определения невалидного цвета мы используем отрицание !

Этот код намного проще читать и редактировать. Появился новый цвет? Добавляем в массив и все.

Протестируем как это работает:

Почему массивы эффективнее switch/case?

Это просто компактнее, вот точно такой же функционал, только вместо if используется switch/case:

Гораздо больше кода. Плюс потребуется добавлять каждый раз проверку case. Данный вариант стоит использовать, когда у нас выполняются разные действия относительно каждого варианта.

Проблема с вложенными условиями

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

Код правильный, но его сложно читать из-за вложенного условия, приходится выглядывать где начинается и где заканчивается то или иное условие.

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

Примечание перевода

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

В данном случае, функция vote выполняет не совсем тот функционал, который от нее ожидают. Vote означает голосование и вначале статьи автор об этом прямо говорит, но тем не менее она еще и валидирует входные параметры (а именно, возвращает информацию об ошибке???).

Лучше всего разделять подобные действия. Если функция отвечает за голосование - значит она и должна это делать, а не возвращать информацию обо всем сразу (ошибки, статус голосования). Вывод ошибки должен выполняться иным способом, либо выполняться в рамках другой функции.

Вот, например, решение через try/catch.

Через try/catch

Так мы можем детально обработать каждую ошибку в нашей функции, а не принимать строку и потом думать, что с ней делать (ошибка к нам пришла? или не ошибка?)