RuboCop started out being a pretty fair representation of a “style guide” for Ruby, and I can’t thank you enough for your work. It’s saved me a lot of time and trouble, and helped newer developers get started writing great looking Ruby! But over the years I feel like a lot of superfluous rules began getting added to this supposed community style guide that I don’t remember anyone really having a discussion over. It seems like for any syntactical decision that can be made, there’s a RuboCop rule telling you which choice to make, even though it doesn’t have any context over why you made that choice.
Here’s a great example. I don’t think and / or continuance should be used in this context:
if something? and something_else?
# do stuff
But I use it all the time in this one:
redirect_to some_path and return if something?
But RuboCop will make me rewrite that latter one into:
IMO this looks a lot worse.
It’s stuff like that…RuboCop IMO needs a huge cleanout, most of the cops need to be disabled by default, with the ability to add ones in places that you feel are appropriate. Additionally, I think RuboCop’s existing cops should be modified to understand the context in which they are running, and possibly have that context altered by RuboCop plugins (for example, rubocop-rails might be able to tell RuboCop that you’re running in a Rails app, so some of the cops make sense in some places)
I feel like the standardrb gem is a response to this. Have you tried it instead? I use it for the sidekiq codebase.
For a long time I had it on my todo to check what exactly is changed in the default configuration there. I appreciate the goal of the project, but experience has thought me that finding complete consensus on style in our community is never going to happen. Or at least quite unlikely to ever happen. :-)
Well, standard is there for people who do want to use an opinionated tool. Rails vs Sinatra, right?
Fair point, although I guess you can say RuboCop is opinionated as well - it has some defaults for everything. :-)
I haven’t, but I’ve heard good things. Will check it out.
Aesthetically, I agree, but fwiw I think the RC recommendation here is absolutely superior for a codebase being worked in any kind of team setting.
The problem with the first is that it forces the reader to understand the fine points around the difference between and and && – and the writer to get those correct. Safer to avoid it entirely. I see it as a case of safety and simplicity trumping aesthetics.
Funny enough the example you gave was recently fixed (see https://github.com/rubocop-hq/rubocop/issues/7795). :-)
But I understand your point. Perhaps we went overboard here and there and RuboCop became too heavy-handed in certain cases. When those things happen gradually over the course of many years from time to time it’s hard to notice them. Doing sweeping changes is always alluring, but for everyone who wants those there’s also someone objecting, so we have to approach changes carefully. Hopefully at some point we’ll get to implementing some context-specific functionality.