Комментарии 73
НЛО прилетело и опубликовало эту надпись здесь
Зачем — не знаю. Если работать через класс SLR, как в примере на ГитХабе, то будет и подсветка, и автокомплит в IDE.
А то, что приятные глазу команды процессора в машинном коде заменены на всякие операторы и идентификаторы у вас неприятных ассоциаций не вызывает?)
Читабельность важна.
Сам думал написать питоновский модуль для более приятной работы с регулярками, но пока руки не доходят.
Сам думал написать питоновский модуль для более приятной работы с регулярками, но пока руки не доходят.
ИМХО классическая регулярка читабельней и нагляднее.
Во-первых, регулярные выражения можно разрывать комментариями. Во вторых, можно заводить метапеременные, которые использовать в выражениях.
НЛО прилетело и опубликовало эту надпись здесь
Подскажите, пожалуйста, что это за метапеременные такие? Пытался гуглить "regex metavars", но безрезультатно.
Судя по названию, это позволяет использовать куски регулярок несколько раз, чего очень и очень не хватает. Но я так и не смог найти, как такое можно сделать — обратные ссылки и именованные группы матчат лишь тот конкретный текст, который они сматчили в первый раз.
Или вы имеете ввиду определение переменных с кусками регулярок в самом языке, из которого они вызываются, а потом конструирование из них финального выражения через подстановку?
man 3 pcrepattern, раздел subpatterns as subroutines.
Регулярка типа (sens|respons)e and \1ibility даст совпадение в случае sense and sensibility и response and responsibility, но не sense and responsibility. Если же использовать (sens|respons)e and (?1)ibility, то заматчится и sense and responsibility.
А если бы изначально синтаксис регулярок был на словах, а сейчас предложили бы использовать символы — возникли бы ассоциации с Brainfuck?
Не обязательно в коде это пихать — можно препроцессор использовать и внешние файлы, да и подсветка есть.
Не обязательно в коде это пихать — можно препроцессор использовать и внешние файлы, да и подсветка есть.
НЛО прилетело и опубликовало эту надпись здесь
скорее кобол уже
НЛО прилетело и опубликовало эту надпись здесь
А я запомнил так, что на клавиатуре $ идет перед ^, а в регулярках наоборот: $ — конец, ^ — начало.
Для меня это как-то само собой разумеющееся. Хотя использовал регулярки не сотни раз.
Никогда не задумывался на счет этих символов. Может циркумфлекс ассоциируется так, что он не полностью занимает пространство символьное, а доллар на всю строку, и вроде даже больше других символов.
Никогда не задумывался на счет этих символов. Может циркумфлекс ассоциируется так, что он не полностью занимает пространство символьное, а доллар на всю строку, и вроде даже больше других символов.
Сначала подумал, было, написать про «Владимирский астрал, эзотерика», но потом решил, что не буду.
А почему нет? Мне нравится идея. Не думаю, что сам бы использовал, т.к. к регуляркам привык, но для новичков — вполне бы сгодилось.
Картинку xkcd про единый стандарт уже постили?
Как средство обучения rx было бы, как мне кажется, вполне удобоваримо. Хотя для тех кто синтаксис уже освоил, вероятно будет неудобно.
НЛО прилетело и опубликовало эту надпись здесь
Относительно последнего утверждения, позволю себе с Вами не согласиться. RX — это инструмент, если он был создан — значит на то была причина, кто-то этим пользуется и получает то, что ожидает. Мне, к примеру, очень нравиться использовать данный инструмент и постижение его окупилось многократно в дальнейшем.
Сайт не отвечает, видимо его постиг хабраэффект.
Для разъяснения и тестирования регекспов есть, например, отличный ресурс: https://regex101.com/
А вводить новый непонятный синтаксис регекспов — не слишком хорошая идея.
Главная проблема регекспов в том, что они write-only. Описанный в статье подход эту проблему решает. Хотя любители однострочников на перле негодуют, да.
Не знаю, буду ли использовать, но запомню, что существует.
Не знаю, буду ли использовать, но запомню, что существует.
Проблема трудночитаемости регулярок решается так же, как проблема трудночитаемости обычного кода — выравниванием и комментариями. Во многих языках поддерживается, но, к сожалению — не во всех.
Проблема чтения машинных кодов решается в выравнивании кода и расставлении комментариев. Но мы же не используем машинные коды правда?
Синтаксис регулярных выражений — это уже мнемоническая надстройка над внутренним представлением, как ассемблер над машинными кодами. Предлагаемый в статье вариант не создает новый уровень абстракции, а просто заменяет одну строку на другую, более длинную — как если бы вместо
mov ax, 0 пришлось писать set first register to value zero.
Разница в том, что эту строку вполне сможет понять человек без предварительной подготовки (по крайней мере, после пары примеров).
А регулярки читаются не сильно хорошо.
А регулярки читаются не сильно хорошо.
Сложность понимания синтаксиса регулярок, имхо, преувеличена. На первый взгляд они выглядят пугающе, но по факту возможные элементы можно пересчитать по пальцам — группы, квантификаторы, альтернативы, штук пять спецсимволов и всякие редкие вещи типа опережающих проверок. Всё это можно запомнить за вечер, а с подсветкой синтаксиса становится еще проще. Так что всё упирается в сложность самого выражение — проверку email-адреса по RFC одинаково невозможно постичь в любой форме записи.
Остается вопрос того, стоит ли доверять человеку без подготовки править код, руководствуясь наивным пониманием синтаксиса. Зачастую это чревато возникновением сложноуловимых багов — например, неопытный программист на C или JS может написать
Остается вопрос того, стоит ли доверять человеку без подготовки править код, руководствуясь наивным пониманием синтаксиса. Зачастую это чревато возникновением сложноуловимых багов — например, неопытный программист на C или JS может написать
if(a = true) и долго удивляться, почему сравнение не работает, как надо.
Пример в начале статьи совсем плох.
Во-первых он уменьшается примерно раза в два, ликвидировав неиспользуемые группировки и объединив перечисления. Во-вторых, экранирование в перечислениях не нужно. И получается вполне читабельно:
И, наконец, Прекратите проверять Email с помощью регулярных выражений!
После небольшой тренировки небольшие однострочные регулярки воспринимаются достаточно быстро. А вот словесный многострочный аналог требует больше времени для чтения.
Сложные выражения в SLR займут экран, воспринимать будет даже сложнее, чем открытый в отладчике (упомянутый выше regex101, например) оригинал.
В целом: за реализацию, конечно, жирный плюс, но, будет ли востребовано, покажет время. У меня сомнения.
Во-первых он уменьшается примерно раза в два, ликвидировав неиспользуемые группировки и объединив перечисления. Во-вторых, экранирование в перечислениях не нужно. И получается вполне читабельно:
^[0-9a-z._%+-]+@[0-9a-z.-]+\.[a-z]{2,}$И, наконец, Прекратите проверять Email с помощью регулярных выражений!
После небольшой тренировки небольшие однострочные регулярки воспринимаются достаточно быстро. А вот словесный многострочный аналог требует больше времени для чтения.
Сложные выражения в SLR займут экран, воспринимать будет даже сложнее, чем открытый в отладчике (упомянутый выше regex101, например) оригинал.
А есть специальные сервисы для визуализации regex
В целом: за реализацию, конечно, жирный плюс, но, будет ли востребовано, покажет время. У меня сомнения.
Проверка имейла регуляркой по большому счёту может быть сведена до /.+@.+/, но это же просто пример. Можете написать автору и предложить свой пример, заодно потестируете новую тулзу.
Вы немного не уловили… Сократить регулярку != урезать. nitso сократил, а вы урезали. Хотя проверять email регулярными выражениями достаточно непрактично.
Лучше всё же, использовать грамматики, а не "очеловечивать" регулярки. Например, для вашего парсера урлов можно запилить такую грамматику на grammar.tree:
URL is
PROTOCOL
string =://
DOMAIN
optional
string =:
PORT
PATH
optional QUERY
PROTOCOL is list-of LETTER
DOMAIN is
list-of
list-of LETTER
string =.
LETTER
list-of LETTER
PORT list-of DIGIT
PATH is
string =/
optional list-of symbol except =?
QUERY is
string =?
optional list-of symbol except =#
LETTER is symbol =abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
DIGIT is symbol =0123456789
А можно ссылочку? А то гугл выдает только хип-хоп дуэт.
https://habrahabr.ru/post/248147/ кажется это оно. Там есть раздел про этот grammar.tree
Собственно ощущение что это и есть придумка господина vintage.
Собственно ощущение что это и есть придумка господина vintage.
НЛО прилетело и опубликовало эту надпись здесь
А какой символ порекомендуете для маркера начала сырых данных?
НЛО прилетело и опубликовало эту надпись здесь
Чего люди не придумают, лишь бы не учить регулярные выражения.
А учить там — с гулькин нос, по факту.
А учить там — с гулькин нос, по факту.
По факту получили Builder для регулярок, что неплохо (и даже можно подумать про портировать на другие языки).
Отдельный язык для такой задачи кмк перебор. Т.е. пока не ясно, как это использовать для самостоятельных задач.
Отдельный язык для такой задачи кмк перебор. Т.е. пока не ясно, как это использовать для самостоятельных задач.
У Rebol/Red есть невероятно удобный и читабельный PEG диалект(parse).
Первый пример из статьи.
test: "superb@ya.ru"
digit: charset [#"0" - #"9"] ; еще один диалект.
letter: charset [#"a" - #"z" #"A" - #"Z"]
symbol: charset "._%+-"
rule: [
some [digit | letter | symbol]
"@"
2 [letter | "."] any [letter | "."]
]
parse test rule
Уважения заслуживают такие люди, как автор этого языка, которые делают Своё.
НЛО прилетело и опубликовало эту надпись здесь
Непонятен профит, это как обратный alias по сути, не очень комфортно. Регулярные выражения познаются не так сложно и не менее трудно читаются, дело легкой привычки.
Одно begin with, вместо циркумфлекса уже настораживает.
Одно begin with, вместо циркумфлекса уже настораживает.
Меня вот больше напрягает literally "@" вместо просто "@". Но зато действительно сложные регулярки, со всякими несъедающими группами, отрицаниями и переменными, может стать легче читать (а главное — редактировать).
Чуть выше уже оставлял ссылку: https://www.debuggex.com/r/xfu903DPxHkmoOpz
Очень помогает отлаживать сложные выражения.
Очень помогает отлаживать сложные выражения.
Как уже было замечено выше, на самом деле нужен не компилятор regExp, а декомпилятор регулярок (как в сервисах визуализации в комментарии выше). И вот если бы оно умело работать в обе стороны — вот это было бы дело!
Ну реально: Вот вы бы отказались от такого сервиса?
Ну реально: Вот вы бы отказались от такого сервиса?
Если хочется красоты, то можно использовать альтернативу — https://en.wikipedia.org/wiki/Parsing_expression_grammar. Использовал PEG в lua — довольно-таки удобно.
Прямо regex с человеческим лицом. Ожидаемо.
Вопрос насколько будет жизнеспособным, а это со временем увидим.
Вопрос насколько будет жизнеспособным, а это со временем увидим.
Классический сухой регекс:
/^(?:[0-9]|[a-z]|[\._%\+-])+(?:@)(?:[0-9]|[a-z]|[\.-])+(?:\.)[a-z]{2,}$/i
Это мусор, который генерирует библиотека что ли? Потому что в .NET я ручками написал бы так:
(?inx)
^
[ 0-9 a-z \._%\+- ] +
@
[ 0-9 a-z \.- ] +
\.
[ a-z ] {2,}
$Ну и что более читаемо: это или ваша портянка?
Странно, что до сих пор никто не напомнил про эту статью:
Хватит писать регулярные выражения. Используйте вербальные выражения
Хватит писать регулярные выражения. Используйте вербальные выражения
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
SRL — Simple Regex Language