Как стать автором
Обновить

Комментарии 7

Отличная статья! Понимаю, что тут примеры для демонстрации, но хотел бы заметить:


Как результат, мы реализуем несколько полезных функций, которые вы впоследствии сможете использовать в своих проектах.

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


Состоит ли строка только из букв?

/[A-ZА-ЯЁ]+/i.test('Њ') дает false (македонская кириллица, и да, я придераюсь.)


Является ли значение числом (целым или с плавающей точкой/запятой)?

Игнорирует возможность использовать разделители (пробелы, например, нижнее подчеркивание), а так же как экспотенциальную нотацию (1.23е33), так и более специфичные (0b1100). И если специфичные нотации редкость, отделять разряды запятыми достаточно популярно. А главное, parseInt (parseFloat) хорошо справляются, хоть есть и свои проблемы.


Является ли значение номером сотового телефона?

Игнорирует возможность написать 008 вместо +8 (это вполне легально). И вообще, номера телефонов парсить регулярками огромное зло, хотя и раздражает, что нет стандартного способа работы с номерами кроме как невероятно раздутой google-libphonenumber. В целом, номера создают не столько проблем, как email, но тоже достаточно. (Ну и если вы скажите "я только для России разрабатываю и игнорирую городские номера" я отвечу: даже только для России быстро может понадобиться необходимость поддерживать иностранные номера. Ну т.е. если кто-то приехал домой на недельку и не смог себе пиццу заказать — будет обидно).


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

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

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

Я о том же, что следует использовать библиотеки / готовые протестированные решения если они есть. Но если нет или не подходят, иногда стоит рассмотреть иные варианты. Например, конечные автоматы гораздо проще расширять в будущем, потому что с специфичными условиями регулярки быстро теряют хоть какую-нибудь читаемость. Правда, признаю, конечные автоматы грамотно написать та ещё задача, может даже сложнее чем регулярку.

Регулярка - это и есть конечный автомат. Если вы не знали.

Конечный автомат конечному автомату рознь. Регулярка работает на них, или, если хотите, это специальный язык описания правил для конкретного конечного автомата. Однако распарсить js регулярками - задача прям мягко говоря не тривиальная, а вот самописный конечный автомат для этого будет… сложный, но несопоставимо более простой чем регулярка, которая не будет сходить с ума от вложенных в скобочки символа комментария. (Конечно, лучше взять готовый парсер или генератор парсеров на крайний случай, но это исключительно для примера).

// Определяем, является ли строка HTML-тегом

const isHTMLTag = (str) => /(^<([^>]+)>$)/i.test(str)

До первого ">" внутри значения атрибута. Таки да, внутри кавычек можно уголки. Регулярки не подходят для хтмл, о чем уже много раз.

  1. У вас есть проблема.

  2. Вы используете регулярные выражения для ее решения.

  3. Теперь у вас две проблемы.

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