Peer Code Review Guidelines

Code reviews are an important part of the software development process. They are an opportunity to find bugs, errors, and flaws in the code, but also provide a way to improve code quality overall. You will find that in your software engineering career you often spend as much time (if not more) reading and reviewing code than writing new code.

One of the less obvious benefits of doing code reviews is knowledge transfer. By reviewing a peer’s work, you will learn new things. These might include best practices and new approaches for dealing with problems, and you’ll also gain an understanding of their particular part of the codebase.

Choosing a Pull Request to Review

Each PR needs two peer code reviews. Ideally, review something that you have some level of basic familiarity with. Once you’ve selected a PR to review, please leave a comment so that other students know you’re working on it.

Testing

Inspect the tests that are included in the PR to determine whether any edge cases were missed. If the PR lacks test cases, this is a problem that needs to be addressed. Suggest tests that the developers should add.

Go through the code once to get an idea of what it’s doing.

Run any test cases and verify they pass. Try adding new inputs / tests to see if you can break the code. Look for values that are hard-coded that may not need to be.

Some things to try:

Code Walkthrough

After thoroughly testing the program, you’ll need to do a complete code walkthrough. This will help you:

A big part of this phase is suggesting improvements to the code. Sometimes two functions can be combined, loops can be refactored in a more straightforward way, etc. You are free to use static code analysis tools to help you do this.

Formatting

For your final pass, focus on formatting. Formatting should be consistent. If the project already has established formatting guidelines, they should be followed by the new code.

As a reviewer, focus on major issues here only.