Peer Code Review

In the peer code review, your tutor assigns you to review the pull requests of 2 other pairs. In the same way, 2 other pairs review yours. Your tutor sets these assignments, and they change with each assignment. Your tutor will post the GitHub usernames. To find a pull request, open that pair’s repository on GitHub and open their pull request from the assignment1 branch.

Each pair gives 2 reviews in total. You and your partner split them, so each of you writes the review for one of the 2 pull requests. Your goal is to provide helpful, specific feedback that improves the correctness, design, readability, and maintainability of their code. Write your review comments in your own words. Note: Your grades for the peer code review are based on an accurate review, not the ratings you give/receive for correctness, code style, and design.

To successfully complete a peer code review, you should:

  1. Understand what changed.
    • Open the Pull Request and skim the title/description.
    • Review the Files Changed tab to identify the main additions/edits.
    • If commits are organized, skim commit messages to understand intent.
  2. Review supporting materials (if provided).
    • Read any accompanying documentation (e.g., description, screenshots).
    • Use these materials to understand the author’s design decisions.
  3. Leave in-line comments on the code.
    • In the Files Changed tab, leave both:
      • Positive notes (what’s well-structured, clever, clean)
      • Constructive feedback (bugs, edge cases, unclear logic, overcomplicated solutions, style issues, etc.)
    • Comments should be specific and actionable (point to the exact line, explain why, and suggest an improvement).
    • Comments can also be clarifying questions.
  4. Complete the Peer Code Review Template.
    • Copy-paste the template into the Conversation tab in the Pull Request view.
    • Fill out all sections and submit the comment as your review.

Peer Code Review Template 

# Peer Code Review

## Summary (1-3 sentences)
Briefly describe what the pull request does and what the main changes/additions are.

---

## Correctness
Check the box for each requirement you can confirm is satisfied based on the PR and evidence (tests, screenshots, docs, output, etc.):

- [ ] Core functionality works as intended
- [ ] Handles edge cases and error conditions appropriately

### Evidence / Notes
- What evidence did you use to verify correctness (tests run, screenshots, sample output, reasoning from code)?
- If anything seems incorrect or incomplete, describe what you observed and where.

---

## Design 
Choose one:

- [ ] Exemplary - Clean, modular, easy to follow. Strong separation of concerns. Minimal complexity.
- [ ] Satisfactory - Works well overall with minor complexity/redundancy or small opportunities to refactor.
- [ ] Needs Improvement - Hard to follow, overly complex, tightly coupled, or missing structure.
- [ ] Missing/None - Design is unclear or not reasonably maintainable.

### Explain your choice
- Are any functions/classes doing too much or too long?
- Is the logic modular and reusable where appropriate?
- Are responsibilities clearly separated?
- Are there confusing dependencies, duplication, or overly complex logic?

---

## Code Style
Choose one:

- [ ] Exemplary - Consistent formatting, clear naming, helpful comments, follows style guide.
- [ ] Satisfactory - Minor style inconsistencies, but overall readable.
- [ ] Needs Improvement - Naming/formatting/commenting issues reduce readability.
- [ ] Missing/None - No consistent style; readability is severely impacted.

### Explain your choice
- [ ] Variable/function/class names are descriptive and consistent
- [ ] Formatting/indentation is consistent
- [ ] Comments/docstrings clarify non-obvious logic
- [ ] Code follows project/course style guidelines

## Inline Comments 
Did you add any inline comments in the Files Changed tab? (So that the author of the PR doesn’t miss your inline comment)

- [ ] Yes
- [ ] No