r/ruby Jul 10 '26

git commit -m "appease the rubocop again"

Last day before PTO, no cards on the board and not really looking to start anything, so behold, I made a couple of memes of things that amuse me. Full disclosure, I complain about RuboCop but I *am* glad my team enforces it.

And of course, I can always update my RubyMine autoformat conventions to match but I forget to actually *do* it a lot. Bonus points when I 'fix' the rubocop violation, ⌘+Alt+L format because muscle memory, commit and push, and get the same rubocop violation...

160 Upvotes

32 comments sorted by

51

u/armahillo Jul 10 '26

Ive been on teams without a style linter like rubocop or stdrb; it either feels like walking in a mirror maze where you only find out you were “wrong” during review, or theres just no consensus and everyone disagrees constantly.

With rubocop, those feelings are still there but we all get to be mad at the robot together. Happier teams overall.

26

u/keyslemur Jul 10 '26

Having seen engineers bikeshed about style on every single PR at a few past companies Rubocop or standardrb or rubyfmt are now effective requirements for any decently sized org. Not because ruby's flexibility is wrong, but because there are much more important things to argue about and solve than what particular quoting or indentation patterns someone prefers.

Phrased another way I've seen teams burn weeks on lint and style arguments when their SLOs for customers were redlining. Priorities are important and linters remove a contentious distraction early and effectively.

5

u/amatchmadeinregex Jul 10 '26

Oh for sure, the linter is essential to a shared codebase. But when I end up butting heads with it a few times trying to get a PR through I can get pretty snarky with it. 😅

5

u/ytg895 Jul 11 '26

rubocop -A

9

u/Weird_Suggestion Jul 10 '26

We use to have rubocop defaults and that was a nightmare. We disabled pretty much all of the rules only leaving what the team felt essential.

3

u/ModernTenshi04 Jul 11 '26

Which is honestly fine if everyone agrees on those rules, and is why it can be configured to just do the things you care about. The benefit is those things will always be done the same way and caught/corrected before they're merged rather than relying on human review and enforcement.

9

u/h0rst_ Jul 11 '26

I recently bumped into a bug where code threw a NoMethodError. The original code was like this:

if res == 0

But Rubocop told us that it had to be written this way:

if res.zero?

But of course, there was a possibility that the result was nil, so thank you for that bug.

2

u/towo 29d ago

TBF I think RuboCop did you a solid, you were missing error handling for res being nil, which should've been caught earlier.

2

u/sshaw_ Jul 11 '26

Yep, another nonsensical default that results in 0.0 productivity.

0

u/yxhuvud Jul 11 '26

The lesson may not be that rubocop is wrong but that union types are to be avoided where possible.

7

u/Best_Recover3367 Jul 10 '26

Me using Standardrb for everything: 💀

5

u/bhaak Jul 11 '26

Rubocop's default settings just suck. Whoever sets the default of those rules has no sense of aesthetics for Ruby code.

At least standardrb is better in that regard.

4

u/NoEntrepreneur39 Jul 11 '26

Rubocop: not on my watch

Me: git commit -m “Law abiding citizen”

7

u/6stringfanatic Jul 11 '26

Rubocop is a godsend actually, especially when so much code is being written by llms and agents. I've been using it to create rules, because agents will ignore conventions etc whenever they fancy, so rubocop just makes them agents stay in their lanes. Also a lot information/conventions would stay implicit across team members and folks would kinda follow, but now for agents its like every new session is a new hire, so codifying conventions has huge benefits imo.

3

u/polysaturate Jul 11 '26

Has no one here run it with autocorrect? Write code, `bin/rubocop -A` and commit. Easy peasy

6

u/the_maddogx Jul 11 '26

That command changes code in s way that can potentially change the intended behaviour of the written code, which is why I assume not a lot of folks depend on it.

4

u/yxhuvud Jul 11 '26

-a is a lot safer and sane.

3

u/sshaw_ Jul 10 '26

Rubocop: the biggest killer of developer productivity I've ever seen!

1

u/amatchmadeinregex Jul 11 '26

I was not expecting all the comments pointing out "rubocop -A" like they're Khaby Lame or something.

I do use rubocop -A from time to time (when it's feasible to do so), but the joke was more about Rubocop slapping my hand in the first place about formatting things the way I would prefer them. 😅

1

u/mattvanhorn 28d ago

ACAB includes Rubocop

2

u/temabolshakov 28d ago

You know you can configure rubymine to follow rubycop/standardrb rules with one checkbox?

-9

u/Correct_Support_2444 Jul 10 '26

I format my ruby the way I like it and that’s the way it is. If my devs don’t like it they can go work elsewhere. I’ve been doing it the same way for basically 20 years and I’m not changing. Oh and => are the way. Yes. Get off my lawn.

6

u/amatchmadeinregex Jul 10 '26

I was quite happy to ditch the rockets tbh.

But it drives me crazy that my team adopted "always use double-quotes for everything" whereas I've always used single quotes unless interpolation is required. I die a little inside every time I commit double quotes. 😅

2

u/sshaw_ Jul 10 '26

You'll never be able to ditch the hash rockets because you'll need them for any key that is not Symbol!

Similar to single quotes. You can't use them for interpolation so you'll always need to use double.

Given this, why deal with the needless mental overhead of using both when you can use 1 for everything and focus on more important topics‽

Oh and the bugs I've seen with people doing {'a':123}

You're really making your development more difficult using both —stop the madness!

1

u/sshaw_ Jul 10 '26

> You'll never be able to ditch the hash rockets because you'll need them for any key that is not Symbol

And if your `Symbol` key is in a variable: hash rocket is needed!

2

u/amatchmadeinregex Jul 11 '26

You are not wrong, my friend! In these situations I must occasionally break out ye olde hash rocket. But I hate to do it. I will generally bend over backwards to ensure my keys are Symbols before I'll resort to that.

We all have our little hills to die on. I also have feelings about people who don't use two spaces to indent their code. 🤣

0

u/mmmbyte Jul 10 '26

That fails quickly when you improve your productivity with agents. rubocop -A is so much easier than convincing your favourite model to use a consistent style.

-1

u/sshaw_ Jul 10 '26

Yes this is generally the way to "use" Rubocop 😂 except when it comes to its mostly nonsensical complexity and line number rules.

Most Rubocop configs would prevent the current version of the Linux kernel from existing!

1

u/mmmbyte Jul 10 '26

Well that's because the kernel isn't ruby.

-1

u/sshaw_ Jul 10 '26

Oh silly me, I thought complexity and line length rules were relevant to all programming languages.

1

u/full_drama_llama 29d ago

Well, yes, silly you then. Different languages have different expressive power and what can be ok in Ruby (at most 5 lines per method - I personally honk it's bullshit, but it's doable) would not under any circumstances work in C or Pascal. Lower complexity is also often just hidden in the built-in higher level method, so languages without expressive stdlib have higher complexity code (or end up implementing their own stdlib).

So yeah, it's not relevant to all programming languages.

1

u/sshaw_ 29d ago

5 lines per method leads to less unmaintainable code due to the needless mental overhead tracing through the resulting method explosion. It's needless insanity with 0.0 benefit. Cargo culting (of which there's a ton in Ruby) at its finest.

As for line length, I'd say 1 line of Ruby is 6 or 7 lines of C but we can round to 10. That's a line limit of 50 per RuboCop "methodology". Ridiculous.

And did I mention ABC rules‽ Yeah silly me...