Please, let the linter do its job. Stop doing code reviews indicating all the empty lines, white spaces, and other nitpick things.
I agree that a heterogeneous code simplifies the reading but recognizes that some things are personal taste. It’s not useful to apply your preferences only in a few lines if the rest of the code is not coherent.
So please, rely on a linter, Rubocop is a good option for Ruby, but there are other alternatives.
You can discuss defining the rules as long as you want, but not on every pull request. I prefer not to invest too much time defining the rules. In the case of Rubocop, I usually start with the default config, maybe even add some extensions, like the Rails or Performance one. Then, I can modify the rules on demand, depending on the team’s taste and the project’s requirements.
It’s important to define a strategy to maintain Rubocop’s warnings. I like to auto-fix all the warnings with
-a and sometimes
-A. If something else is still raising warnings then I generate a
--auto-gen-config. Then I can run
rubocop as part of my continuous integration and mark it as a failure if it raises a warning.