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.
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.