Code review should check architecture, logic, security, tests, and readability. Architecture: does this change fit the system design or is it fighting it? Logic: does the code do what it claims to do, and does it handle edge cases? Security: are we introducing vulnerabilities, leaking data, or trusting user input? Tests: do they cover the change and its edge cases? Readability: can the next person understand this code without asking the author?
Formatting and style rules belong in a linter. If your team has not configured a linter and formatter to auto-enforce style, fix that in the tooling instead of leaving it to PR comments. Don't hold a PR back because you prefer camelCase and the author used snake_case. Configure Prettier and move on.
The worst case is the "nit" review: 47 comments, all prefixed with "nit:" as if that prefix absolves them. "Nit: extra blank line." "Nit: I would put this import above the other one." A PR blocked for days over whitespace costs more than the whitespace.
A useful review comment looks like this: "This retry logic doesn't have exponential backoff, so if the service is down we'll hammer it. Here's a suggestion." It catches a real problem and offers a solution. "I don't like that you used reduce instead of a for loop" passes off a preference as expertise.
A practical rule: block a PR only for a bug, a security issue, or an architecture problem, and mark everything else as optional. Fix the real problems so we can ship the code.