[cowanon22]

This is why I now use tools like SonarQube (commercial static code analyzer) to drive most code quality reviews. SonarQube also gives justifications for all of it's recommendations, so it serves as a training tool as well.

The only I things I manually look for in reviews are overall readability, sensible naming, high level adherence to the architecture/design, and data system/database/API queries.

After 20 years of writing code and leading teams, I've found that most of the stuff developer blogs and the OOP community fret over simply doesn't matter in most cases. The high level interfaces are often more important than the low levels details, and static code analyzers do a decent job of pointing to problems. I've almost never seen bad code that didn't also have many issues in the static analyzer.

It also matters what kind of code you are writing - foundation code or something that will be used by thousands/millions of developers should have a higher bar than some internal one off. However, I've seen enough very profitable companies running on total crap code to believe that code quality is the most important thing.