I have a potentially controversial opinion on code reviews - that they have a low enough signal-to-noise ratio that they provide minimal value, unless they are

I have a potentially controversial opinion on code reviews - that they have a low enough signal-to-noise ratio that they provide minimal value, unless they are conducted using a formal but living checklist/process. I strongly believe that code reviews have to be goal-oriented or they become vectors for excessive opinion airing (read: bikeshedding and holy wars). I've spent way too much time getting feedback that I either disagree with and end up arguing over, or feels completely pedantic or time-inconsiderate (e.g. loosely-specified comments about code style during a tight deadline), that could be eliminated by a few things: 1. identifying and documenting the value that the code review is intended to provide. 2. constraining criticism to those that actively provide the intended value. 3. where a decision point arises based on reviewer/author disagreement, create a consensus decision within the team and document it in a standards doc so that the debate never needs to be had again. In my experience, when this process is followed well it leads to a feedback loop that accomplishes the following: 1. Generating a consensus-driven standards document based on the primary values of the team. 2. Creating a code review process that is exclusively aimed at "linting" new code against the standard, and raising exceptions where the standard does not provide a "correct" approach. 3. Ensuring minimal discrepancy between code reviews coming from different devs. The process doesn't even need to be that formal - just 2 github wiki pages, one for the standards and one for the code review process.