Awesome Reviewers

Follow the project’s established formatting conventions consistently, and when the linter and formatter disagree, resolve it explicitly rather than leaving noisy diffs or inconsistent code.

Always use braces for conditional blocks, even single-line ones, matching the project’s curly rule:
```
// preferred
if (!location) {
  return false
}
// avoid
if (!location) return false
```
Since eslint-config-prettier disables curly, add an explicit override in the eslint config to keep this rule enforced instead of relying on manual review.
When ESLint and Prettier conflict (e.g. quote style with escaped apostrophes), don’t just accept the clashing output—add a targeted // eslint-disable-next-line <rule> comment on that specific line so intent is clear and CI passes cleanly.
Consolidate multiple imports from the same module into a single import statement, including type-only imports:
```
// avoid
import { parseBody } from './body'
import type { BodyData } from './body'
// prefer
import { parseBody, type BodyData } from './body'
```
Consider adding an ESLint rule to catch duplicate imports from the same file automatically.

Use parentheses to make operator precedence explicit when mixing &&/|| in a single condition, so the logic is unambiguous at a glance:

if (contentType !== null && (contentType.startsWith('multipart/form-data') || contentType.startsWith('application/x-www-form-urlencoded'))) {
  ...
}

Keep semicolon/statement-start conventions consistent with the rest of the codebase (e.g., a leading ; before a line starting with [ or ( in a no-semicolon codebase) rather than introducing a different pattern in new code.

Applying these conventions consistently reduces review churn, avoids CI failures from linter/formatter conflicts, and keeps the codebase readable and uniform.

This site is open source. Improve this page.