[cr1222]

Things like maintainability are hard to objectively define and measure, but still important. If you let issues pile up a medium-to-large team working on a codebase for a few years can turn it into something completely incomprehensible and and impossible to chain.

I make a lot of comments along those lines when I review code and I think overall it's helped significantly with technical debt and it would be very limiting to not be able to use my judgement on these matters when reviewing code. I definitely always provide some explanation, e.g. some examples of why the test coverage is inadequate, or why the code seems more complex than necessary. But this still relies to a significant degree on the reviewer's intuition and judgement.

I think it's reasonable to look at code and ask "will someone be able to understand this in a year's time?" or "how likely is someone to introduce a bug when changing this logic?". You won't get totally objective answers but I think you get some worthwhile insight.

There are various measures you can look at as heuristics - cyclomatic complexity, that sort of thing. I think also requiring good test coverage steers things in the right direction since it's often easier to simplify the code than to achieve full coverage.

The "finding bugs" criteria also doesn't really work if the code is so complex that a reviewer can't convince themselves of its correctness.

[YZF]

I definitely agree with the overall sentiment; one needs to be constantly on guard to maintain a good code base. I don't think it's just a matter of code review though. A bad team will take this "how to do a code review" and still produce bad stuff. A good team probably doesn't need "how to do a code review". The best code reviews I've participated in were more informal affairs. They're generally in person discussion rather than the distant commenting on some review platform.