how to review code good and do other stuff good too

• A quick glance at the diff to spot anything obvious
• Pull it down and run it locally with a fresh install of all dependencies
  • open the console and watch for errors being logged
  • does this patch cover the AC in the story?
  • does this patch resolve repro steps in the bug/defect?
• Comb through code line by line:
  • Are there sanity checks in place (no infinite loops/recursion, etc)?
  • If there's complex or hard to follow code, can it be simplified?
  • Can comments be replaced with better variable/method names?
  • Are there comments where we need them?
  • Are the comments good?

    The proper use of comments is to compensate for our failure to express ourself in code.
    Note that I used the word failure. I meant it. Comments are always failures.
    We must have them because we cannot always figure out how to express ourselves without them, 
    but their use is not a cause for celebration.
    ...
    Why am I so down on comments? Because they lie. Not always, and not intentionally,
    but too often. The older a comment is, and the farther away it is from the code it describes,
    the more likely it is to be just plain wrong. The reason is simple. Programmers can’t realistically maintain them.
        - Robert Martin, Clean Code
    

  • Do the unit tests cover the edge cases that "will never happen"? That's where things break.
  • Do the unit tests cover our code or framework internals?
  • Does the automation cover the right things?

This is a living document. Feel free to comment on things you disagree with and add things that are missing!