Code reviews and 'ideal' code

Once I worked in the team that was way too much focused on code "quality": all methods should have proper comments, and if the comment text is long then it should be nicely formatted using html markup, reviewers pointed out missing dots at the end of comment sentence, double space was also a problem that had to be fixed with no exceptions, all local variables have to be annotated with 'final' when possible to 'highlight semantics', back and forth discussions on naming etc. etc. etc....

And reviewers were routinely checking and pointing out each and every occurrence where the code style was not up to these standards.

The code looked really nice, perfect. One problem was that team's productivity was not as good as it could be... But the way bigger problem was that quite often code reviews didn't catch bugs that were found later in production (and as result caused way more problems and requiring way more efforts to fix it).

Human's focus/attention capacity is limited. Human can retain attention on some (quite limited) set of objects, when you focus on something it implies that something else is loosing your attention.

So when you pay too much attention to code style you are losing focus of other aspects. This is simply nature of our mind.

Well, somebody may think 'I can make a code review pass focusing on code style, then another pass focusing correctness and later take another look checking error handling' - while sounds reasonable this is quite naive and wrong: our time is limited, our mind is getting tired (you can't do code reviews for several hours straight preserving the same attention to details). This approach is not sustainable in a long run.

The solution is 'prioritization': focus first on what is important! What is important? In general: bugs - errors in code, logic, potential bugs - things that can go wrong when the code is run in production. If you want more specific answer - well, it depends. It depends on context of change, sometimes it is error handling (e.g. API related code), sometimes scalability... it is a separate big topic on how to approach code reviewing.

As a short conclusion I want to quote (approximately) a head of an org that I've worked at some time ago: "The goal of the code review is to prevent problems, everything else is not much important when you are not finding bugs. If you disagree with this please come to my office and I'll explain why you are a threat for the team and for the company"

P.S.: Some people may not realize the problem if they work with the code that is not complex enough or their' intellectual capacity' is high enough to compensate so far (rare case).