Code Review

Professional Development

Ben Baumer

Smith College

2024-09-24

What is code review?

• Systematic quality assurance for code
• Dates back to 1976
• Performed by someone else
• Best practice for improving code quality

Why do code review?

• Better code quality
  • readability
  • consistency
  • understandability
• Fewer bugs
• Knowledge transfer
• Increased sense of mutual responsibility

This isn’t your code, this is our code

When to review code?

• Code reviews should be short!
• Best practices from 2006 Cisco study: > Lines of code (LOC) under review should be less than 200, not exceeding 400, as anything larger overwhelms reviewers and they stop uncovering defects. > The total review time should be less than 60 minutes, not to exceed 90. Defect detection rates plummet after 90 minutes of reviewing.
• Pull requests should be small!
• Dovetails with our recommendation for more frequent, smaller commits

How to review code

• Does this code accomplish the author’s purpose?
• Think like an adversary, but be nice about it.
• Think about libraries or existing product code.
• Does the change follow standard patterns?
• Think about your reading experience.
• Does the code adhere to coding guidelines and code style?
• Google Engineering Practices code review documentation

In practice

• Send a pull request (PR)
  • For R code, run styler beforehand!
  • Tag someone else as a reviewer
• If you’re tagged, review the PR
  • Make line-by-line comments, questions, etc.
  • Approve or request changes
• Cycle continues until the PR is merged
  • It’s not rude to request changes!!

This isn’t your code, this is our code