I believe there are two problems at play here. 1. Inconsistency causing maintainability/readability problems. 2. The desire to avoid discussions about style w

I believe there are two problems at play here. 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"