#rubocop — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #rubocop, aggregated by home.social.
-
A new #RuboCop release is out with many bug-fixes and performance improvements! Read all about those here https://github.com/rubocop/rubocop/releases/tag/v1.88.2
Cheers!
-
Did anyone ask for a bunch of #RuboCop bug-fixes? Here you go https://github.com/rubocop/rubocop/releases/tag/v1.86.2
-
RuboCop: Layout/LineLength: Line is too long. [81/80]. One character. The centurion is not amused.
-
Another rubocop/standardrb gripe:
Style/EmptyLiteral: Use hash literal {} instead of Hash.new
Nah, I have my own heuristics for when to use which one. If it's inside a block with braces, I assert that:
# the "approved" butthole syntax
let(:params) { {} }looks worse than
# ain't nothing wrong with this
let(:params) { Hash.new } -
A new #RuboCop release is out with a TON of bug-fixes https://github.com/rubocop/rubocop/releases/tag/v1.86.1
Enjoy!
-
🎉 Behold, the latest in the never-ending quest to make #Emacs less user-friendly! The #Rubocop creator has decided to grace us with #Neocaml, because apparently OCaml wasn't hard enough already without some #TreeSitter magic. 🤪 Embrace the chaos, developers! 🖥️🔧
https://github.com/bbatsov/neocaml #developerchaos #HackerNews #ngated -
Neocaml – Rubocop Creator's New OCaml Mode for Emacs
-
This must be one of the best articles about #RuboCop I ever came across https://lovro-bikic.github.io/300-days-of-rubocop/
It made really proud of the work we've done with the project, and the great community around it!
-
RuboCop is pretty awesome. I use it a lot at work to autocorrect generated code, apart from general usage.
Today was the second time I've written a custom RuboCop formatter, and it's so easy, convenient and quick to do.
https://docs.rubocop.org/rubocop/extensions.html#custom-formatters
-
This morning we have a lot of #RuboCop bugfixes for all of you https://github.com/rubocop/rubocop/releases/tag/v1.84.2 Enjoy!
-
Moar #RuboCop bug-fixes for everyone! https://github.com/rubocop/rubocop/releases/tag/v1.84.1
Enjoy!
I also realized we skipped RuboCop 1.83 due to an issue in the release script... Oh, well...
-
A new version of #RuboCop is out with many fixes and improvements! (https://github.com/rubocop/rubocop/releases/tag/v1.84.0)
Enjoy!
-
Almost 15k lines of #Ruby, bodily dragged into the present, catching up on ~6 years of updates.
Test coverage increased from "uhh basically nothing" to 65%.
And, thanks mostly to #Rubocop, the code is way neater and more maintainable now.
We even accidentally fixed some longstanding bugs!
Hugely excited for the next major dev task: moving away from "Amazon" "Web" "Services" for file hosting.
-
Should I use `private_constant`? I'm lazy and define constants in `private` sections so they are near to the private methods which use them and don't care if developers can access them manually. But apparently rubocop cares, so maybe I should? Or should I just disable the `Lint/UselessConstantScoping` rule?
-
Is there any value in allowing "new" rubocop cops? I've been bitten by them dozens of times, however I wonder whether there's value in tackling their inaccuracies head on and submitting feedback early rather than later.
-
#RuboCop 1.82 is out with many small improvements and bug-fixes! See the release notes for all the details https://github.com/rubocop/rubocop/releases/tag/v1.82.0
Enjoy the new release and have a happy holiday season in style!
-
If I'm working on projects which uses script languages, I want to have at least linting set up and covered in CI. However if the project didn't do any linting before you don't want to fix hundreds of issues at once destroying git history.
The right way to do this is to only lint the git diff of changes and make sure only new or modified code is linted. Developers on the project prefer such an approach.
I needed something for #ruby so I hacked rubocop-git: https://gitlab.com/routenbuch/routenbuch/-/commit/a2b763de1b77c9d4a7811302ef659bbc02d5fafc
-
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 -
-
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 -
@MoskitoHero there's a #ruby convention about that:
https://rubystyle.guide/#safe-because-unsafe
But I've seen them disabled on most #rubocop configurations I've seen so far.
There's also something similar in #reek:
https://github.com/sdurko/reek/blob/master/docs/Prima-Donna-Method.md
Anyway, I do support that convention, but I lean more on not use them that often. I do prefer "safe" methods (functional style much) and I don't use it for side effect - it's implicit in their module names.
-
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 📈😩.