[bioneuralnet]

Right? I seem to be the only high-level SWE at my company who hates RuboCop. Some of it's fine (e.g. no globals, use x.count { ... } instead of x.select { ... }.count). But so many of the rules are obsessed with trivial details like the "right" style of blocks to use (do vs {}) or "" vs '' for strings. Pointless busy work. I think the dumbest is requiring "def (x=true)" over "def (x = true)". Seriously, why could that possibly matter??

[viraptor]

I see that as: it doesn't matter, therefore let's do one consistent thing and you'll never get a person saying "this should be x=true". RoboCop forces it one way and I never have to have a syntax/formatting discussion again.

You may think it really really doesn't matter, to the point that whatever form should be accepted. But then, would you accept my "def foo (x =true ,y= false )"? I've seen enough PRs with that kind of code to know that people will submit it one day.

[skissane]

> I think the dumbest is requiring "def (x=true)" over "def (x = true)". Seriously, why could that possibly matter??

For Python, I use ruff to autoreformat my code into a consistent style. The CI pipeline fails the PR if the style is violated it. Fixing it is a one-liner. Actually, if you use VSCode’s ruff extension, a zero-liner, since it auto-formats on save.

For Java, I use Diffplug Spotless for a similar experience.

One advantage of forcing the code to be auto-formatted, is it makes diffs cleaner - you eliminate diffs where someone just changed the code style, since the code style never changes.

[hrdwdmrbl]

Why does it matter when there is auto-fix-on-save? I just write whatever, hit ctrl+s and the code is fixed. The result: The code is "fixed" based on whatever rule and it doesn't cost me a thing. I don't think about it and I don't lift a finger.

But I do personally appreciate the tidiness of code-consistency.

[bioneuralnet]

That's my argument - if we collectively care, it should happen automatically. Alas, no one else seems bothered by the status quo.

[Gigachad]

Most of these trivial rubocop rules autoformat so it doesn't bother anyone. The ones that don't are usually odd things like code that doesn't run or things with the same name, which can't be safely autofixed.

[hrdwdmrbl]

Some of these rules do support autocorrect

[codesnik]

strange, I think default rubocop setting is actually to add spaces around = in default values in functions. https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Layout/Spa...

this is an override in your project's .rubocop.yml

For me it's a bit opposite, I use and appreciate rubocop for simple formatting, not all of the rules but some of them, where autocorrect works. Recently I reformatted a big old project which was written by pretty sloppy developers who didn't care about whitespace, and it's just easier to work with now.

But I truly hate when rubocop tries to be smart about method calls, amount of lines in methods and amount methods or some other "code smell" metric.

yes, the tool allows to check for it, but it's not THAT smart. I have reasons. I'd happy to explain those reasons on code review to a human, but I'm not that happy to appease a dumb tool.

So, please do it as rails does, use bare minimals, something like https://github.com/rails/rubocop-rails-omakase

and ask other developers to stay away from .rubocop.yml

[wutwutwat]

`””` vs `''` isn’t just a style rule. In Ruby there are performance implications with double quoted strings. Strings in double quotes are interpolated for variable substitution, whereas strings in single quotes are processed literally, no variable replacement overhead. Is it going to matter for most code? Probably not, but good to know nonetheless imo.

[tomstuart]

This sounds intuitively true, but it’s a (very persistent) myth: https://www.viget.com/articles/just-use-double-quoted-ruby-s...

[wutwutwat]

TIL. Thanks

[codesnik]

I also am not sure why it's intuitive at all. Article doesn't mention why - ruby has a parse phase, it doesn't scan your string byte for byte every time it runs looking for an interpolation. During the parse those "foo#{bar}" are replaced by something like 'foo'.dup << bar.to_str in the bytecode, but that happens only when parser hits #{ in a double quoted string, there's no penalty for that and it happens just once. Only really old, naive interpretators parse source code each time line is hit. (Or some weird ones, where interpolation can change semantics and argument count, like tcl and bash.)

[codesnik]

this isn't true for any half-ass interpretator out there. Perhaps some old PHP executable was slower with different quotes, but it's not true for ruby for decades. In bytecode there's zero distinction between "" and ''. Don't believe me? benchmark.