Bscale Handbook

Code Review

Our code review process and expectations for reviewers and authors.

This page is a placeholder and will be fleshed out in the future.

Code Review

Code review is one of the most important practices we have. It ensures quality, shares knowledge, and catches issues early.

For PR authors

  • Keep PRs small — aim for under 400 lines of changes
  • Write a clear description — explain what changed and why
  • Self-review first — read your own diff before requesting review
  • Link the issue — every PR should reference an issue or ticket

For reviewers

  • Be kind and constructive — critique the code, not the person
  • Ask questions — if something is unclear, ask rather than assume
  • Approve with comments — don't block on nitpicks; leave them as suggestions
  • Respond within 24 hours — keep the feedback loop tight

What to look for

  1. Correctness — does the code do what it's supposed to?
  2. Readability — can someone new understand this in 6 months?
  3. Tests — are edge cases covered?
  4. Security — any injection risks, exposed secrets, or auth bypasses?
  5. Performance — any N+1 queries, unnecessary re-renders, or large payloads?

Merge policy

  • At least one approval required
  • All CI checks must pass
  • Squash merge to main (we keep a clean linear history)

Remember: The goal of code review is to build better software together. Every review is an opportunity to learn.