Conversation
|
Disabled |
|
With the current slate of cops, we get: Of the remaining after autocorrection: DetailsIf we exclude If these seem reasonable, we can go through and address them one-by-one. |
|
The suggested cops seem fine, also they lead to more readable code in my opinion, so not only performance gains! I wonder why |
3d298ab to
9d49549
Compare
7fc81d0 to
91e54e3
Compare
|
TIL:
|
ae78e5d to
554cb3e
Compare
deivid-rodriguez
left a comment
There was a problem hiding this comment.
I really love these, I should use RuboCop more 😄.
Only cop I'm "meh" about is Performance/CaseCmp, because while I think the other cops make the code better (not only faster), this one I don't love it, because it leaks implementation details about the comparison into our code (although I admit well known for most: zero means equality).
As a tiny note, a9aa5e86c9a5c728105d4748784f4fe908343b94 mentions "Disable Performance/ArraySemiInfiniteRangeSlice", but I don't see that cop anywhere?
Anyways, thanks for doing this!
There was a problem hiding this comment.
This sounds like an upstream false positive, right? I can report it if so.
There was a problem hiding this comment.
Yes, that's a false positive. It suggests an incorrect fix of all_parts.all?(part.to_i.to_s).
There was a problem hiding this comment.
This one may be skippable upstream too, and also Pathname#delete_prefix sounds like a nice feature request. I can take of requesting both if they make sense.
There was a problem hiding this comment.
Yeah, there's its complement Performance/DeleteSuffix has a similar problem.
It would be great if RuboCop didn't generate a false positive for Pathname. In rubocop/rubocop-performance#245, they marked it as not safe, but I don't know of any other changes beyond that.
Conversely, it'd also be nice if Pathname responded to #delete_prefix and #delete_suffix. I was surprised those methods didn't exist already.
There was a problem hiding this comment.
Is removing the above comment intentional?
There was a problem hiding this comment.
Good catch! Those must've been lost in the shuffle when the splat was moved to the end.
Require rubocop-performance in configuration Disable Performance/OpenStruct Disable Performance/SelectMap Disable Performance/ChainArrayAllocation Disable Style/MultipleComparison
Disable Performance/RedundantEqualityComparisonBlock in pull_request/labeler.rb
Disable false positives for Performance/DeletePrefix
Disable Performance/MethodObjectAsBlock in mixfile_sanitizer.rb
Fix test failures introduced by &block signature changes
554cb3e to
d00b8aa
Compare
Nice call-out. I reverted that commit after reading the docs for
I'm not the biggest fan of Edit: Actually, fact-checking that last statement, I realized that @deivid-rodriguez Thanks for your offer to upstream fixes for the false positives. I think that'd be a great thing to do. Please let me know how I can help. 😃 |
|
@mattt Ok about Regarding false positives, my offer was to report them, not fix them 😅, but my experience when reporting this kind of issues upstream is that they usually fix them quickly, so we'll see :) |
Related to #5588
RuboCop Performance is a RuboCop extension that adds linters for Ruby (anti-)patterns that have an outsized performance impact.
This PR adds
rubocop-performanceas a development dependency todependabot-commonand updates the shared.rubocop.ymlfile to enable Performance cops.