Sometimes good enough is good enough. Every code review has opportunity for improvement, but an over-eager reviewer can dampen both morale and productivity. It’s better to lead a horse to water than to dump a bucket on its head.

That said, here are some short criteria for effective code review.

If I can create either:

  • a realistic scenario where the code will break as-written (a failing test case)
  • a realistic future product use-case where the code will be difficult to work with as-written

then I will present that scenario to the author and let them figure out what is wrong/non-optimal.

In doing so, be fair and partial in your reviews, and use infinitive articles and no possessives. For example say “the function here can be rewritten like so” rather than “your style can be improved”.