You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's very hard to tell if people are using the global variables stored by String#match, but perhaps can include a configuration option for this?
Good point! I forgot the global variables. Performance/RegexpMatch can be aware of the global variables, so the include cop will be able to support them also by using Performance/RegexpMatch code.
But I guess we can just omit supporting match and =~ from include cop.
RegexpMatch cop corrects match to match if it is possible, so the include cop can detect match + simple regexp usage after running RegexpMatch cop even if the include cop does not support match and =~ directly.
Agreed. Generally the use of the globals has been on the decline, so I guess we can also advise people not to do it. I guess the only thing the globals have for them is that they are more compact than the alternative.
Is your feature request related to a problem? Please describe.
String#include?
is faster thanString#match?
with a simple regexp.https://gist.github.com/pocke/eeffeaa58ddcc35f862f6e1aca593b21
I wrote a few benchmarks, and I got the result.
The difference is small in simple cases (str1 and str2).
But there are clear differences if the string is long.
Describe the solution you'd like
Add a cop to detect
String#match?
with simple regexp.And I guess the cop also can detect
String#match
andString#=~
if it is used as a condition.Describe alternatives you've considered
nothing
Additional context
We already have Performance/StartWith and EndWIth. We can refer the cops to help to implement it.
The text was updated successfully, but these errors were encountered: