Code Review Best Practices

Catching bugs before they ship is one benefit of code review, but not the only one — it's also how a team spreads knowledge (a reviewer learns what changed and why), keeps a shared codebase consistent (naming, patterns, structure), and gives newer developers concrete, specific feedback on real code they wrote.

A useful review checklist for an Apex change:

• Correctness — does the logic actually do what the PR description claims?
• Bulkification (Module 7) — is there a SOQL query or DML statement inside a loop?
• Naming and clarity (this module's earlier lesson) — would a stranger understand this code?
• Tests — are there tests, and do they cover the real edge cases, not just the happy path?
• Scope — does this PR do exactly one thing, or has unrelated code snuck in?

BLOCKING: "This SOQL query is inside a for loop — this will hit
           governor limits with more than 100 records. Please move
           it outside the loop before this can merge."

SUGGESTION: "Optional: `isEligible` might read slightly clearer as
             `hasQualifyingScore` — up to you."

Not every comment carries the same weight. A blocking comment identifies something that must be fixed before merging (a real bug, a governor limit risk); a suggestion offers an optional improvement the author can take or leave. Being explicit about which is which respects the author's time and avoids unnecessary back-and-forth.