Ask HN: How do you conduct code reviews?
I have some idle time and have been asked to look into producing a code review checklist. This is quite an interesting matter, as to me, much like programming, code reviewing is a highly idiosyncratic, ineffable, thing, and so I wonder whether the community here has somehow managed to formalize it.<p>There are obvious things to put in such a checklist (e.g. short and legible methods, check for potential null reference exceptions) but sometimes even glaring bugs can sneak through code review. A recent example: in a PR, I noticed a method call had been deleted and replaced with nothing, and asked the developer about it. The developer assured me the functionality that the method had provided was implemented elsewhere in the PR, and that indeed seemed to be the case.<p>Turns out, that other implementation did not in fact cover all the functionality the deleted method call had provided, and an entire feature was lost due to that PR. In light of this, something else that could go in a checklist is &quot;when a method call is deleted, verify what the method did&quot;. Another is that deleting that method call meant the method had no references (dead code), yet was not deleted, so neither I nor the other reviewers saw the method body in the diff, which would have shown that a feature was being lost. Another item could be &quot;If method calls are deleted, check for dead code&quot;.<p>Do you have a formal method for conducting code reviews? What things do you look for?