For the examples in the post, by all means discuss as a team and agree to exclude them.
This comment comes with the the smell of the idea that there is a right and wrong way to format code, when in fact with, Ruby at least, there's a lot of nuance that can be added in the way the article describes.
There are legitimate reasons for expressing the same functionality of code in different ways to express intent, something that Rubocop unfortunately isn't able to judge.
> I would rather work in a team that agrees to follow some set of conventions than than one in which everyone does things the way they prefer personally.
These aren't the only two options, there is a middle ground, in which you use cops that solve problems that are unambiguous, such as tabs/spaces for initial indentation, which brings me to the next point:
> For the examples in the post, by all means discuss as a team and agree to exclude them.
My main problem with Rubocop (which is a great tool) is that everything is enabled by default (and this seems to be encouraged) and the tool is overused. To me Rubocop smacks of the classic programmer problem of discovering you can do something, and so applying the solution to all the places the solution can be applied. "Because we can, not because we should".
I'm sorry you smelled that; I don't believe there is one way to do format code, but the opposite. I am saying that working in teams it's convenient to work to the team's style rather than your own particular likes and dislikes. Mainly avoid getting into code review Jenga about style preferences.
1. Inconsistency causing maintainability/readability problems.
2. The desire to avoid discussions about style within a team.
If you're talking about 1. here then what you're talking about is consistency as a tool that can be used to further the goal of maintainability/readability, but as with all tools it can be applied too broadly to problems it doesn't suit, which I would argue includes the subtlety and nuance around the intent of some code rather than the function, and so to force consistency there, and to nullify intent, harms the persuit of the end goal.
Point 2. is in my experience so rare that I'm tempted to assume it's just a post-rationalisation used to justify the pleasing sensation programmers get from making things the same. However, assuming it does exist, just in companies I've not experienced, this isn't really a goal that in my opinion is best served by a linter, once you've got to the point that you've automatically fixed all the issues that are obvious (such as lead spaces, syntax errors, security issues etc).
Everything you're left with after this point is a programmer either expressing intent, or making an unsound style choice, and this is best solved in code review. Expressing intent is valuable, especially in a language like Ruby where there is room for nuance.
If you've got two developers fighting over preferred style, bring in a senior developer to educate about this and perhaps even bring it up in the employee review. If you've got two senior developers who disagree about the style of a piece of code, then they should be expressing their opinions in a non-argumentative and suggestive style:
Senior a> "I would prefer to see this code written like this, but this is a personal preference"
Senior b> "I wrote it like this to show x intent" or "I have amended the code as you suggested"
What about a world where style concerns aren't part of a code review? Style debates provide the superficial appearance of a code review while offering no useful review of security, architecture and intent.
I like a super basic stripped down rubocop, and instead of a focus on "style", a more considered focus on readability.
Anyway remember you're writing code, not poetry. The inclination to act as if you're writing the latter without any kind of cost/benefit analysis is a major reason I dislike working with ruby devs. If only I were actually writing for powerpoint slides rather than for concrete business ends!
One thing that annoys me (and I'm not saying that you're doing it here) is that the people who say it's not worth arguing about are usually the ones doing the arguing. Like, if it makes no tangible difference either way, then just let people do whatever. It literally doesn't matter. But that's not acceptable to the "it's not worth discussing" people, and suddenly it becomes very important to discuss consistency. And not just any old consistency. We can't just flip a coin. No, it has to be consistent with their favourites, which are correct and therefore not worth discussing.
My personal standard is that if somebody suggests a rule and nobody really opposes it then great, enable it. If there is opposition, then it stays disabled until one side can persuade the other. If they truly care about consistency then they are welcome to change sides at any time. Attempts to browbeat the opposition should result in some private feedback from their line manager. There are exceptions for things that matter, but a lot of this stuff just doesn't.
Last time I raised a formatting change with our team, I got replies like "the default settings have been agreed with the community"(a blatant lie) or "I wasted enough time in my life discussing formatting" (okay, this guy has to write C# mostly, the standard formatting is already a lost cause there anyway).