-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
optimize
favors shortness over readability
#208
Comments
@fregante, thanks for the report. Yes, I see how optimizer may lead to less readable outputs, however, the resulting regexp object in this case is still would be more optimized from the regexp engine perspective (handling simple sequence should be faster in general, than handling a sequence of character classes). To support your use case specifically, optimizer has both, whitelist and blacklist. You can blacklist the |
Ideally though at linting time I get both Then at build/minification time you could apply any changes that conflict with readability but improve speed and size. The first would be called by Since
|
Another everyday example: /http:\/\/[^/]+\/pull\/commits/gi 👆 Readable /ht{2}p:\/{2}[^/]+\/pul{2}\/com{2}its/gi 👆 Nonsense, longer Strangely this only happens if I include that Tested on RunKit
|
I use
regexp-tree
via eslint-plugin-unicorn/better-regex and found that some optimizations lead to less-readable output.Similarly to #135, I'd argue that readability and shortness might not always overlap. I found this specific example, outputted by
regexp-tree
/^\/\/\*\??/
Can you guess what the expected match looks like without spending a couple seconds on the zigzag sequence?
This was written as:
/^[/][/][*][?]?/
Which IMHO is slightly more scannable/readable.
My guess is that this is caused by
charClassToSingleChar
, which makes sense for[\d] -> \d
but worsens what I just showed.The text was updated successfully, but these errors were encountered: