
Почти все основные языки программирования поддерживают регулярные выражения, и многие инструменты статического анализа имеют шаблоны, связанные с регулярными выражениями.
Итак, прежде чем искать, скажите нам: вы ожидаете, что эти шаблоны будут одинаковыми от языка к языку? Абсолютно другой?
Вот что я нашел:
Рубин
Начиная с Ruby, мы можем легко найти два паттерна из двух разных инструментов:
- Неоднозначный литерал регулярных выражений (Рубокоп)
- Запрещает небезопасные регулярные выражения (Brakeman)
Первый относится к возможной двусмысленности, когда использование круглых скобок устраняет указанную двусмысленность.
Вторая — уязвимость ReDOS, связанная с использованием пользовательского ввода в регулярном выражении.
Все идет нормально; они оба имеют смысл.
(вы можете найти подробнее об инструментах статического анализа Ruby в этом посте)
JavaScript
В совершенно другой среде мы также можем найти правила регулярных выражений в ESLint:
Так что же они?
Первые три относятся к возможным опечаткам; четвертый предлагает использовать
var re = /foo {3}bar/;
вместо:
var re = /foo bar/;
(серьезно, можно сразу сказать, сколько там пробелов?)
Два последних предназначены для устранения двусмысленности символа косой черты в определенных случаях (в /=foo/ является ли /= началом регулярного выражения или оператора деления?)
Таким образом, мы в основном ищем опечатки, устраняем двусмысленность и делаем регулярное выражение более удобным для чтения (надеюсь).
Ява
Давайте посмотрим на шаблоны Java:
Здесь мы находим неверный синтаксис, проблему с использованием File.separator в регулярном выражении, возможную опечатку при использовании . или | как регулярное выражение в строковой функции (например, split) и, опять же, уязвимость ReDOS.
(вы можете найти подробнее об инструментах статического анализа Java в этом посте)
Перл
Трудно говорить о регулярных выражениях, не упомянув Perl.
Вот несколько шаблонов регулярных выражений от Perl::Critic:
Сразу видно, что шаблонов здесь больше, чем для других языков в этом посте (на самом деле правил здесь больше, чем во всех остальных языках вместе взятых).
В то время как первое из этих правил касается возможной проблемы в коде, подавляющее большинство из них на самом деле связаны с удобочитаемостью, а некоторые из них также касаются проблем с производительностью (например, чередование отдельных символов и неиспользуемые захваты).
Также интересно отметить, что последние три относятся к использованию модификаторов /s, /x и /m, также для ясности. Подробнее об этих модификаторах можно прочитать в документации Perl, но для краткости:
- /с делает . также соответствует н
- /x разрешает использование пробелов в регулярном выражении
- /m, с многострочной строкой, заставляет ^ и $ соответствовать началу и концу каждой строки, а не только строке.
Если вы хотите увидеть, как может выглядеть плохо придуманное регулярное выражение (как будто вы никогда раньше его не видели), вот пример, который нарушает 7 из этих правил (мы ищем две косые черты, за которыми следует буквенно-цифровой символ и цифра 1 или 2):
m#//([A-Za-z0-9_])(1|2)#;
Это выражение использует символ # в качестве разделителя, фиксирует группы, которые никогда не используются (поверьте нам, мы их не использовали), чередует два символа вместо того, чтобы помещать их в класс, и игнорирует существование именованного класса символов w, используя вместо этого его подробная версия; все это, конечно, в сочетании с отсутствием трех рекомендуемых модификаторов.
Гораздо более чистая версия этого выражения будет выглядеть так:
m{ //w[12] }sxm;
Теперь все проблемы решены, и, скажем прямо, выражение лица стало намного приятнее для глаз.
Подавляющее большинство этих правил связано с четырьмя разными вещами:
- удобочитаемость
- представление
- возможные опечатки
- Уязвимости ReDOS
Изучение этих правил поможет вам лучше писать регулярные выражения.
Как ни странно, хотя некоторые шаблоны присутствуют для разных языков, многие из них отсутствуют; в некоторых случаях это имеет смысл, поскольку они относятся к сложности языков; в других может быть просто недостаточно спроса на них или, возможно, это может быть просто вопросом времени, когда кто-то их внедрит.
В любом случае, и независимо от того, какой язык(и) вы используете, настоятельно рекомендуется использовать инструмент статического анализа в вашем коде, чтобы улучшить его и предотвратить эти и другие проблемы; или, что еще лучше, иметь инструмент, который сочетает в себе преимущества различных инструментов, не нарушая ваш рабочий процесс, например Codacy.
Редактировать: мы только что опубликовали электронную книгу The Ultimate Guide to Code Review на основе опроса 680+ разработчиков. Наслаждаться!
О кодировании
Codacy используется тысячами разработчиков для ежедневного анализа миллиардов строк кода!
Начать легко — и бесплатно! Просто используйте свою учетную запись GitHub, Bitbucket или Google для регистрации.
"НАЧАТЬ"
Первоначально опубликовано на https://www.codacy.com/blog/best-practices-for-regular-expressions/ 30 марта 2016 г.