back

by padolsey·14y ago·view on hn ↗
How would you design a regular expression syntax more intuitively? Personally, I find beauty and simplicity in regular expressions. Sure, they can grow to hideous atrocities, but you can achieve such disastrous feats with any language/syntax. Maybe you could back up your claim of regexes being a disgusting abomination with, at the very least, anecdotal evidence.
2 comments
IMO, the main problem is that the syntax is too terse. The syntax is taken wholesale from the algebraic notation used in mathematics and dropped in unmodified. Essentially, regex code ('cause regexes really are code) is not skimmable.

The greatest syntactical atrocity in regexes is that they don't have the `x` modifier (in Perl parlance) on by default. This means that you can't use whitespace to chunk code into meaningful bits, nor can you comment it to easily document what does what or explain a particularly hairy section to handle some weird edge case. This means that regexes degenerate a lot faster than ordinary code in terms of readability.

Edit: Misplaced close paren.

"Easy to write, hard to read". Perl's influence on Regex shows. Which is fine in most cases.

I always wonder what regexes would look like if they were derived from Python instead.

Actually, regex syntax isn't primarily a Perl invention. Regexes as software tools go back to early Unix text processing tools (ed and grep, according to Wikipedia), and Perl took the syntax from those tools.

It is true that Perl reformed the syntax in important ways (to the better, if you ask me), and later on extended it a lot, but it's certainly not a Perl invention.

A typical regex looks like this:

  \b[A-Z0-9._%-]+@[A-Z0-9.-]+\.[A-Z]{2,4}\b
Which is also what happens when a cat walks across the keyboard.
There's nothing wrong with regex syntax. But there _is_ something wrong with the formatting of your example: it's not readable. Perhaps you _should_ write (assuming Java-syntax):

  (?x:              #standard token is an uppercase letter, digit, dot, or hyphen
    \b
    [A-Z0-9._%-]+   #1 or more of standard token, underscore, or percent sign
    @               #at-sign
    [A-Z0-9.-]+     #1 or more standard tokens
    \.              #dot
    [A-Z]{2,4}      #2 to 4 uppercase letters
    \b
  )
We can easily optimize for readability with regex syntax.
You can say that about pretty much anything if you aren't familiar with the syntax. That looks pretty readable to me - certainly far more portable and readable than equivalent code.

[It's also perfectly obvious that if this is an attempt to match email addresses that it's not a very good one - but I don't know the context where it's supposed to be used, it might be good enough for whatever the author intended].

I find that perfectly readable, except for the \b which I hadn't seen before. It's matching an all-uppercase email address.
There's plenty of upper case e-mail addresses that won't match that expression.
Well, if you want to be fully compliant you can go for this 6kb monster

http://ex-parrot.com/~pdw/Mail-RFC822-Address.html

/i
There's characters missing[1] and the tld is too short[2]. And even if that's fixed, we still don't match internationalized addresses or actually validate that the e-mail address exists. You're probably better off with something like...

   if "@" in email and "." in email.split("@")[1]:
       send_verification(email)
...but you should probably also check for common misspellings like "gmial.com" etc.

[1] http://en.wikipedia.org/wiki/Email_address#Syntax [2] http://en.wikipedia.org/wiki/List_of_Internet_top-level_doma...

Call me weird, but I find that very readable.