Skip to content

code reviews

Christopher P. Brown edited this page Feb 24, 2020 · 3 revisions

Code Reviews

It's about making code better.

Why do code reviews

  • Get better at:
    • (presenters) talking about and explaining your own code
    • (reviewers) reading and understanding somebody else's code
  • Build trust
  • Share knowledge across teams

What to review

  • 200 - 400 lines of code
  • Timeboxed to 60 minutes

What to review for

Correctness, Clarity, Effeciency, and Style

  1. Correctness: Does it do what it's supposed to do?
    • Off-by-one
    • Copy & paste / Spelling
    • Edge cases & exception handling
    • Respect for patterns
    • Data validation & security
  2. Clarity: Can someone other than the author describe what's going on?
    • Naming conventions
    • Function length & purpose
    • Library usage
    • Respect for patterns
  3. Efficiency: What's the performance impact?
    • Database queries
    • DOM manipulation
    • Asynchronous JavaScript / Digest Cycles
    • Using an ORM
  4. Style: Does this meet your style standards?
    • Comments
    • Line length
    • Naming conventions
    • Indentation

How to do reviews

Avoid generalities. Don't say:

  • This is messy
  • Nice!

Be specific. Do say:

  • This function is missing a return type.
  • Changing this nested if...else block to a lookup table will reduce the cyclomatic complexity quite a bit.

Who and When?

Denver Engineers will meet in person once a week to do code reviews

Resources

Clone this wiki locally