Code Review Checklist

Torus PR Code Review Checklist

General Guidelines

• Understand the Purpose

  • Is the purpose of the PR clearly explained in the description?
  • For Bug Fix PRs, ensure the PR description includes:
    • A detailed explanation of the diagnosed root cause.
    • A clear description of what was done to fix the issue.
    • A description like "This fixes a bug in course preview" is not acceptable.

• Code Clarity and Readability

  • Is the code well-organized and easy to read?
  • Are functions appropriately named, concise, and follow consistent naming conventions?
  • Is there unnecessary commented-out code, debug logs, or obsolete code included?

• Tests

  • Are there sufficient tests (unit, integration, and/or end-to-end) for the changes?
  • Do the tests cover edge cases and failure scenarios?
  • Are the tests named clearly to indicate what they are testing?
  • For bug fixes, is there a regression test to ensure the bug won’t reoccur?

• Documentation

  • Is all new or changed functionality properly documented?
  • Are comments included where the code is not self-explanatory?
  • For major changes, is there an update to the README, Wiki, or API documentation?

• Performance and Scalability

  • Are there any potential performance bottlenecks in the code?
  • Are there any places where serial queries are executed that a single query could replace?
  • Does the code handle larger datasets or increased load gracefully?

• Error Handling and Logging

  • Does the code gracefully handle possible errors or edge cases?
  • Are descriptive error messages returned where appropriate?
  • Are useful logging messages at an appropriate logging level present?

• Dependencies

  • Are there any new dependencies added? If yes:
    • Are they necessary and justified?
    • Are they actively maintained and secure?

• Code Structure and Modularization

  • Are the changes appropriately scoped, avoiding a mix of unrelated updates?
  • Are modules, contexts, or components organized logically?
  • Are there any opportunities for further modularization or code reuse?

Elixir/Phoenix-Specific Items

• Are Ecto queries well-written and make proper use of composable query functions?
• Are Phoenix contexts appropriately used to separate concerns?
• Are controllers lightweight, delegating logic to contexts?
• Are LiveView components split logically with minimal redundancy?
• Are changes to the schema properly handled (e.g., migrations and validation logic)?

Frontend (if applicable)

• Does the frontend code (HTML, TypeScript, React, etc.) follow best practices?
• Are there no inline styles, and does it leverage Tailwind CSS?
• Is the UI/UX consistent with the system's design principles?

Backward Compatibility

• Are the changes backward-compatible with existing functionality?
• Is there any need for data migration, and if so, is it handled correctly?

Deployment Readiness

• Are there any deployment concerns or special considerations noted?
• Does the PR include clear steps for post-deployment verification?

---

Tips for Reviewers

• Spend time understanding the problem and proposed solution before diving into the details.
• Be constructive and provide actionable feedback with examples where possible.
• Confirm that all automated tests and checks have passed before proceeding.
• You should run the branch locally and verify the bug fix or feature

---

Review Approvals Should Consider

• The code is production-ready, adheres to standards, and solves the stated problem effectively.
• The team consensus has been reached on any disputed changes.