It seems to me that what you're actually seeing is an entire industry trying to eliminate all code-related issues, specially bike-shedding ones.
This is patently obvious to anyone who was forced to waste their time in code review iterations discussing, say, where a brace should go and how many spaces someone should have added.
(If multiple people are arguing back and forth in code review -- when following the WIR rule -- tell them about the WIR rule and that should settle it. If not, you have bigger problems in your team.)
Why though? I am not going to go with suggestions if they make the code less readable for me!
Just make decision and get on with your lives. Have some kind of linter check for inconsistencies before any human review.
If an organization cannot make a decision on inconsequential bike-shedding it is dysfunctional.
That sounds quite dysfunctional.
(EDIT: Sure, nitpicks may differ, but...)
Worked with two developers who endlessly argued whether or not we should handle a certain bit of complexity in a certain layer or the next layer over, so we ended up handling it in both layers with the downsides of both.
No,it doesn't. It sounds like the expected outcome of not enforcing an established style with automated tools.
All it takes is someone posting a merge request with a bracket out of place, or tabs instead of spaces which screws layout because yes IDEs have custom definitions and a dude happened to have opened a source file with an editor that wasn't properly configured.
Boom, merge request receives two comments pointing out the bracket and how indentation is off.
Congrats, about 20 minutes of your team's day are wasted because that's the time it takes to receive feedback from the merge request, be briefed on the remarks, go through the code and fix whitespaces, commit your change, push those changes, update the merge request, and wait for a team member to review your update.
No drama. No dysfunctional team. No disagreement, even. But those 20 minutes of your life are lost forever.
Unfortunately those also have significant downsides around large-scale refactoring.
What I always do (and advise other code reviewers to do) is to just ask themselves: Does this code follow the local style in the file being edited?
That simplifies things greatly, IME.
I personally get super annoyed when people keep pointing out style issues, but our CI tool can notify me of issues with my commit until the end of time without me getting frustrated with it.
This sort of baseless assertion has no bearing in reality. In a project that hasn't adopted any linting tools and automatic style checks, all it takes is a misconfigured editor to post a change request that fails to comply with style guides. These sorts of absolutes show a complete detachment from reality and absence of any practical experience in the field.
But you are making these baseless assertions yourself?
Obviously you can have issues if you are not using automated linting (both in the editor and on CI). That’s part of the failure.
It also remove all debate in PRs about style and formatting.
(note: before prettier, I was fairly particular about how I formatted my code, and I disagreed with prettier in some cases, but now, I love having one less thing to think about)