Ваш вопрос, кажется, не относится к самим регулярным выражениям, а только к синтаксису , обычно используемому для выражения регулярных выражений. Среди многих хардкорных кодеров этот синтаксис считается довольно лаконичным и мощным, но для более длинных регулярных выражений он действительно действительно нечитаем и не поддерживается.
Некоторые люди уже упоминали флаг «x» в Perl, который немного помогает, но не сильно.
Мне очень нравятся регулярные выражения, но не синтаксис. Было бы неплохо иметь возможность создавать регулярные выражения из читаемых, значимых имен методов. Например, вместо этого кода C #:
foreach (var match in Regex.Matches(input, @"-?(?<number>\d+)"))
{
Console.WriteLine(match.Groups["number"].Value);
}
у вас может быть что-то более многословное, но гораздо более удобочитаемое и удобное для обслуживания:
int number = 0;
Regex r = Regex.Char('-').Optional().Then(
Regex.Digit().OneOrMore().Capture(c => number = int.Parse(c))
);
foreach (var match in r.Matches(input))
{
Console.WriteLine(number);
}
Это просто быстрая идея; Я знаю, что есть и другие, не связанные с этим проблемы с ремонтопригодностью (хотя я бы сказал, что их меньше и меньше). Дополнительным преимуществом этого является проверка во время компиляции.
Конечно, если вы думаете, что это слишком, и слишком многословно, вы все равно можете иметь синтаксис регулярного выражения, который находится где-то посередине, возможно ...
instead of: -?(?<number>\d+)
could have: ("-" or "") + (number = digit * [1..])
Это все еще в миллион раз более читабельно и только вдвое дольше. Такой синтаксис можно легко сделать так, чтобы он обладал той же выразительной силой, что и обычные регулярные выражения, и он, безусловно, может быть интегрирован в компилятор языка программирования для статического анализа.
Я действительно не знаю, почему так много возражают против переосмысления синтаксиса для регулярных выражений, даже если переосмысливаются целые языки программирования (например, Perl 6 или когда C # был новым). Кроме того, приведенная выше очень многословная идея даже не несовместима со «старыми» регулярными выражениями; API может быть легко реализован как тот, который создает регулярное выражение старого стиля под капотом.