I can definitely relate with the introduction paragraph about the joy of solving problems with regex, even ones that seem ill-suited for them. I know people love the “now you have two problems” trope but they’re definitely underappreciated in my opinion.
In a not-too-dissimilar fashion, I once wrote a program (a shell script really) that generates regex which matches a range of numbers (for example, all numbers > 200). It even supports decimal, negative and numbers in different bases (2 to 16). It was initially intended to be used within kakoune, but it also works standalone.
Author here!
I believe the use case was for code search where regex was the only input. This wasn’t really a production use case I had, just answering someone’s question online with a niche problem.
There are no capturing groups necessary here, so naming them would only barely help with readability. What might work is something like how the article constructed the regex and putting that preprocess step behind a rollup/babel plugin.
Even better, use a regular(?) grammar and parse the expression rather than using a regular expression. IMHO, any time you start using capture groups is when you should start thinking about an alternative representation.
Yeah so about that…
Here’s a valid css rgb thing:
(took from here: https://codepen.io/lmmm/pen/gOdYQxd, and updated it a little bit)
maybe don’t try to use regex for something parsed by Webbrowsers.. that didn’t work out with html already
I can definitely relate with the introduction paragraph about the joy of solving problems with regex, even ones that seem ill-suited for them. I know people love the “now you have two problems” trope but they’re definitely underappreciated in my opinion.
In a not-too-dissimilar fashion, I once wrote a program (a shell script really) that generates regex which matches a range of numbers (for example, all numbers > 200). It even supports decimal, negative and numbers in different bases (2 to 16). It was initially intended to be used within kakoune, but it also works standalone.
This malbolge-looking regex won’t pass a code review and won’t ever be maintained.
Make use of named capture groups. This is JS so you don’t have an
/xflag available natively but that can be worked around.I’d suggest reading The true power of regular expressions which was an eye opener for me at the time.
Author here! I believe the use case was for code search where regex was the only input. This wasn’t really a production use case I had, just answering someone’s question online with a niche problem.
There are no capturing groups necessary here, so naming them would only barely help with readability. What might work is something like how the article constructed the regex and putting that preprocess step behind a rollup/babel plugin.
Thanks for the interesting article though!
Even better, use a regular(?) grammar and parse the expression rather than using a regular expression. IMHO, any time you start using capture groups is when you should start thinking about an alternative representation.