4 ms·

Well, maybe if you wrote it like this: mandatory_leading_letters = "^\w+" optional_suffix = "([-+.']\w+)" domain = "\w+" domain_suffix = "([-.]\w+)" tld

Well, maybe if you wrote it like this: mandatory_leading_letters = "^\w+" optional_suffix = "([-+.']\w+)*" domain = "\w+" domain_suffix = "([-.]\w+)*" tld = "\.\w+([-.]\w+)*$" regex = "{mandatory_leading_letters}{optional_suffix}@{domain}{domain_suffix}{tld}" Then you could understand it? Seems to me the trouble isn't with regex but with the decision to write a regex without trying to make it understandable. It is also possible to minify your onto one line in some languages or otherwise obfuscate it; should we then condemn it? If the author had to fix a multi-line regex, I hope that in the process, they understood it enough to break it up into pieces so that the next time it would be more possible to debug. Regex are pretty neat. They are often not the solution. I would not want to use lookaround for example. But also, they are really useful in a lot of cases, and I would hate to not use them because they're capable of being obfuscated.

flykespice 4y ago
+1 this. I only recently started using it exclusively to parse grammar, when the rules got complex so did my regexes, but when I divided my regexes into groups each on their own variable and I formed whole a regex by concatenating these variables, regex was much more concise for me.
thwayunion 4y ago
Yes! I have been writing regexes like this for 20+ years. The "well then just don't write line noise...?" realization comes easily for those of us that spent a few years "maturing out of Perl". Because first you stop writing Perl line noise, and then you realize that regexes are just another part of that line noise (because regex are so common in perl code). Regular expressions DEFINITELY ARE the right tool if the problem that you have is that you need to parse a regular grammar (or near-regular grammar)!!! Like, literally, they are 100% the right tool. Theoretically. Practically. Everything. The. Right. Tool. And they are also the absolutely, terribly, completely wrong tool if you need to do anything other than parse a (very nearly) regular grammar.
puffoflogic 4y ago
Even this is unnecessary. I'd say 99% of people using PCRE-like regexes have never read the documentation and realized `(?x)` exists. We can write the regex like this, including all whitespace: (?x) ^\w+ # mandatory leading letters ( [-+.'] \w+ )* # optional suffix @ \w+ # domain ( [-.] \w+ )* # domain suffix ( \.\w+ ( [-.] \w+ )* )* #tld $ Also, btw, I hope no one is really using this regex. It's wrong; for example it appears to be deliberately designed to fail on IDNs.
- goguy 4y ago
  That's less readable than the original suggestion though.
  - sundarurfriend 4y ago
    Out of context on HN, it looks so. But in my experience, the original suggestion with the separate variables gets pretty hard to keep track of, and ends up making things more confusing. The `(?x)` or `/.../x` version makes it much easier to see things in their place and understand the overall pattern.
    - RheingoldRiver 4y ago
      That's pretty neat, indeed I'd never heard of this, or maybe I had once but I'd forgotten about it if so. I might counter that in a very long regex you'd want to do the assembly in multiple steps, but I can definitely see the appeal of inline comments (perhaps in addition to something like that). I'll try to keep this in mind for the next time I'm dealing with regex. Thanks for sharing!
- atlantic 4y ago
  Outstanding method for commenting regexes. I had no idea about (?x). Thanks for this - I'll adopt it going forwards.
anshumankmr 4y ago
You know that's kind of a fantastic way to do it. Really. How I usually did it was copy the best possible regex from Stack Overflow and see the best possible one that passed my unit tests. Though I really don't know a whole lot about regexes beyond the utmost basics.
ihatepython 4y ago
I love using regexes whenever I need a way to parse HTML. Also whenever I parse nested parentheses, brackets, or braces.
jmort253 4y ago
I like the example using well-named local variables to put together the regular expression into something really readable. It reminds me of the chapters in Uncle Bob's Clean Code book on naming using functions and local variables. When reading the code, unless you're specifically debugging the regular expression, you don't really need to get into the details of validating what the regular expression is doing.

Well, maybe if you wrote it like this: mandatory_leading_letters = "^\w+" optional_suffix = "([-+.']\w+)*" domain = "\w+" domain_suffix = "([-.]\w+)*" tld

flykespice 4y ago

+1 this. I only recently started using it exclusively to parse grammar, when the rules got complex so did my regexes, but when I divided my regexes into groups each on their own variable and I formed whole a regex by concatenating these variables, regex was much more concise for me.

thwayunion 4y ago

Yes! I have been writing regexes like this for 20+ years. The "well then just don't write line noise...?" realization comes easily for those of us that spent a few years "maturing out of Perl". Because first you stop writing Perl line noise, and then you realize that regexes are just another part of that line noise (because regex are so common in perl code). Regular expressions DEFINITELY ARE the right tool if the problem that you have is that you need to parse a regular grammar (or near-regular grammar)!!! Like, literally, they are 100% the right tool. Theoretically. Practically. Everything. The. Right. Tool. And they are also the absolutely, terribly, completely wrong tool if you need to do anything other than parse a (very nearly) regular grammar.

puffoflogic 4y ago

Even this is unnecessary. I'd say 99% of people using PCRE-like regexes have never read the documentation and realized `(?x)` exists. We can write the regex like this, including all whitespace: (?x) ^\w+ # mandatory leading letters ( [-+.'] \w+ )* # optional suffix @ \w+ # domain ( [-.] \w+ )* # domain suffix ( \.\w+ ( [-.] \w+ )* )* #tld $ Also, btw, I hope no one is really using this regex. It's wrong; for example it appears to be deliberately designed to fail on IDNs.

goguy 4y ago
That's less readable than the original suggestion though.
- sundarurfriend 4y ago
  Out of context on HN, it looks so. But in my experience, the original suggestion with the separate variables gets pretty hard to keep track of, and ends up making things more confusing. The `(?x)` or `/.../x` version makes it much easier to see things in their place and understand the overall pattern.
  - RheingoldRiver 4y ago
    That's pretty neat, indeed I'd never heard of this, or maybe I had once but I'd forgotten about it if so. I might counter that in a very long regex you'd want to do the assembly in multiple steps, but I can definitely see the appeal of inline comments (perhaps in addition to something like that). I'll try to keep this in mind for the next time I'm dealing with regex. Thanks for sharing!
atlantic 4y ago
Outstanding method for commenting regexes. I had no idea about (?x). Thanks for this - I'll adopt it going forwards.

anshumankmr 4y ago

You know that's kind of a fantastic way to do it. Really. How I usually did it was copy the best possible regex from Stack Overflow and see the best possible one that passed my unit tests. Though I really don't know a whole lot about regexes beyond the utmost basics.

ihatepython 4y ago

I love using regexes whenever I need a way to parse HTML. Also whenever I parse nested parentheses, brackets, or braces.

jmort253 4y ago

I like the example using well-named local variables to put together the regular expression into something really readable. It reminds me of the chapters in Uncle Bob's Clean Code book on naming using functions and local variables. When reading the code, unless you're specifically debugging the regular expression, you don't really need to get into the details of validating what the regular expression is doing.