back
1 comments
I've always found code review checklists more distracting than helpful. Whatever their length, if you narrow your mind to them, you might miss a lot of issues, in particular very contextual ones that would be hard to generalize in a checklist. Also, when their points are not too trivial to have to be reminded, they often boil down to "check that X is good", without telling you what "good" means.

When I do a code (or text) review, I just look for... anything - as when I'm the one writing. And it's much quicker that scanning the whole code for each point. I read, I (try to) understand, and anything wrong that I'm able to catch will pop up in my head either immediately (for things that don't require much context) or over time (as I get more familiar with what the dev did and tried to do).

If code review is so close to code writing, the code review checklist should just be the coding standards, and experienced devs should have assimilated them already.

What to look for in a code review is mostly having good and multiple reviewers, typically by requiring approval by a number of official reviewers before commits can get merged (ex: OpenJDK).