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 .todo_rubocop.yml with --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.