Совершенный код: плохие и хорошие практики при проектировании параметров функций
2026-02-26 18:57 Diff
https://ru.hexlet.io/blog/posts/sovershennyy-kod-plohie-i-horoshie-praktiki-pri-proektirovanii-parametrov-funktsiy

В этой статье я расскажу про неочевидные примеры неправильного проектирования аргументов функций. Про необязательные параметры в JavaScript, передачу флагов, нарушениях интерфейсов и использовании оператора rest не по назначению.

Некоторые примеры ниже специфичны для JavaScript, остальные встречаются повсеместно

Содержание

Обязательные и необязательные параметры

JavaScript, в отличие от большинства других языков, не проверяет наличие обязательных параметров при вызове функций. Любую функцию можно вызывать без аргументов, и интерпретатор молча выполнит этот код, подставив во все обязательные параметры undefined:

Ситуаций, когда такое поведение желательно, пожалуй нет. Скорее к этому стоит относиться как к легаси, от которого уже не уйти. И его точно не нужно эксплуатировать в своем коде. Почему?

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

Определить эту функцию можно несколькими способами. Один из них такой: const markdown = (text, options) =>. В этом случае, если опции не переданы, то значением параметра options станет undefined. Дальше внутри тела функции уже строятся нужные проверки для работы с этими опциями.

Подписывайтесь на канал Кирилла Мокевнина в Telegram — чтобы узнать больше о программировании и профессиональном пути разработчика

Несмотря на то, что такой код работает и не выглядит страшно, он создает сложный в анализе код. Программисту, которому понадобится воспользоваться этой библиотекой, недостаточно посмотреть в определение этой функции (например, по подсказке редактора). Из этого определения неочевидна необязательность. Ее придется явно задавать в документации, а значит пропадает возможность генерировать документацию автоматически. К тому же не видно, что из себя представляет options. Даже с точки зрения написания функции подобный подход неудобен. Из-за того, что options может менять тип (либо объект, либо undefined), внутри придётся делать дополнительную проверку на то, с чем мы работаем. Если бы там всегда был объект, то такая проверка не понадобилась бы. Правильное определение выглядит так:

Использование ...

В JavaScript существует rest-оператор, который позволяет свернуть значения в массив. Он полезен, например, в функциях, которые работают с переменным количеством однотипных параметров. Например встроенная функция Math.min() принимает на вход любое число аргументов и находит среди них минимальное:

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

У такого определения довольно много проблем. Оно не просто неочевидно, но еще и семантически некорректно. Rest-оператор говорит о том, что функция работает с любым числом путей, но это не так, она работает только с двумя. Это гарантированно запутает тех, кто собирается пользоваться функцией. При таком определении невозможно задать значения по умолчанию. И усложняется обращение к путям внутри самой функции, в худшем случае появится подобный код: paths[0] и paths[1]. Индексы плохо читаются и с ними гораздо проще ошибиться.

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

Флаги

Попробуйте ответить на вопрос, что делает второй параметр в этой функции:

Ответить на этот вопрос практически невозможно. Параметры–флаги, чаще всего, — признак плохой абстракции. Такое встречается, когда в рамках одной функции объединяют, по сути, две и более функций. Флаг тут выступает как переключатель с одного варианта поведения на другой.

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

Иногда флаги — это опции, и в таком случае их лучше заменять на явную передачу опций:

Но иногда, все же встречаются ситуации, где без флагов неудобно. Например функция, которая устанавливает видимость элемента:

Здесь флаг уместен, но очень важно следить за названием функции. Текущее название не очень удачное, потому что оно переводится как «сделать видимым», но по коду видно обратное. Правильно было бы назвать эту функцию setVisibility().

Параметры для внутренних нужд

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

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

В правильной реализации этот параметр не просачивается наружу. Это легко делается с помощью определения внутренней функции, которая и будет вызываться рекурсивно:

Дополнительные материалы