Is there any benefit to packaging up common rubocop configuration into a gem (aka inherited_gem) vs. just bundling said gem from git?
Examples:
https://github.com/ronin-rb/rubocop-ronin
https://github.com/Shopify/ruby-style-guide#readme
ACAB also applies to Rubocop
If you got #rubocop failing on EmptyInterpolation linter in the recent version (v1.76.0), there is good news for you. The issue got fixed - https://github.com/rubocop/rubocop/pull/14245
You might have noticed a record-breaking 7th consecutive bugfix release for #RuboCop (see https://github.com/rubocop/rubocop/releases/tag/v1.75.7). I just wanted to say that's not because the quality of RuboCop dropped, but because I've decided to focus on bug-fixing and polish for a while.
We have plenty of features already! 
#RuboCop celebrated its 13th birthday yesterday! It's amazing how far we've come along and how strong the project is going after all that time. A huge THANKS to everyone who was part of this amazing journey so far. As usual - the best is yet to come!
I added a new configuration option to the `Naming/PredicateName` RuboCop rule: `UseSorbetSigs`. And it’s now released.
If set, it will take into account Sorbet sigs. So it will only complain if the method doesn’t start/end with the right things (like is_, has_, question mark) if there’s a `returns(T::Boolean)` sig.
Setting this option has reduced the number of TODOs for this rule in the `github/github` codebase by over 50%.
I have no idea why I'm getting these rubocop errors. Rubocop seems to think these constants are defined within a `private` section, but they are not. The classes do however include a small `private` section above which is terminated by another `public` keyword, which should not effect the constants below the `public` keyword. I cannot seem to reproduce this rubocop bug in a stand-alone example.
https://github.com/ronin-rb/ronin-vulns/actions/runs/13342739549/job/37269447618
Seriously considering launching myself as able to take on #freelance work on #Ruby, #RuboCop, #Sorbet, etc stuff.
There’s something very satisfying about fixing a list of things and making a codebase better in terms of consistency and developer experience. And I know a lot of people don’t enjoy that.
Very part-time. I love my “real” job and everything else I do (OSS, events). After my maths exam would make more sense. But I’m still bored at weekends and the winter electricity bills are 
.
#Ruby's parser gem is nearly the end of the road https://github.com/whitequark/parser/issues/1046 Moving fully away from it will present some challenges to projects like #RuboCop (mostly because Prism currently misses some of parser's features), but it seems inevitable at this point.
I guess `Integer#allbits?` / `Integer#nobits?` optimizes better than `num & bitmask == result` since it's one method call vs. a bitwise operation and a comparison?
https://docs.rubocop.org/rubocop/cops_style.html#stylebitwisepredicate
Also apparently Style/BitwisePredicate is marked as an unsafe cop. Is there a rubocop configuration setting to disable *all* unsafe cops so I don't have to play wake-a-mole with rubocop?
Apparently rubocop is now recommending using Integer#allbits? / Integer#nobits? instead of `(num & 0xff) == 0xff`. I don't know how I feel about this... I feel like bitwise operations are more explicit.
https://docs.rubocop.org/rubocop/cops_style.html#stylebitwisepredicate
Wondering if rubocop should be in a separate GitHub Actions YAML file that only runs when any .rb file is changed? This might cut down on unnecessary rubocop runs.
#rubocop
I recently ran into an old codebase (~12 years old) without a Rubocop configuration, and figured adding one to existing code wasn't always as easy as it seems.
Here's a little step-by-step guide I wrote on how to tackle this kind of situation:
https://dev.to/lcsm0n/adding-a-rubocop-config-to-an-old-repository-step-by-step-guide-49db
The time has come for a gigantic RuboCop release, that's jam-packed with bug fixes and small improvements https://github.com/rubocop/rubocop/releases/tag/v1.67.0 Enjoy!
@alexanderadam @cam Ever had untuned #RuboCop turn a simple one-line ternary into a tortured mess of if/then or case statements? I have.
Part of the *art* of coding is elegance without losing clarity. RuboCop's default rulesets consistently uglify my code. When teams don't tune the rules they fall back on argument from authority regarding style sheets because `tuning == work`. Standard and rubocop-rails-omakase reduce the burden and avoid trivialities, which is why I like them!
@alexanderadam @cam No, but I know lots of teams where EVERYONE basically runs `rubocop --regenerate-todo` before every commit because they don't have the time, interest, or agreement to prevent untuned #RuboCop from uglifying or distorting code. #Standardrb, and to a lesser extent https://github.com/rails/rubocop-rails-omakase, have many fewer argument-inducing rules so people actually *use* the linters & style guides rather than just ignoring them.
IMHO the default RuboCop rules ruin good #RubyLang code. YMMV.
@mike_k Defaulting to double-quotes is one of the things I love about #standardrb. Actually, the RuboCop Rails Omakase gem is pretty good, too. The only rule in there I hate is the default of enforcing spaces inside square brackets. You can tune that, but then it wants to change a bunch of Rails config files and such, too. Oh, and complaining about trailing commas in Hash and Array literals. Either way, better than the dozens of violations standard #RuboCop emits out of the box!
I’ve got MOAR RuboCop bug fixes for you! (See https://github.com/rubocop/rubocop/releases/tag/v1.65.1) Enjoy!
