Awesome Reviewers

Write code using the shortest, most idiomatic form that remains clear, and stay consistent with the project’s established conventions rather than reverting to verbose patterns. Concretely:

• Use shorthand object properties instead of repeating keys: { path, method, handler } rather than { path: path, method: method, handler: handler }.
• Use optional chaining and nullish coalescing to collapse verbose conditional returns, e.g. return opt?.after?.(await res) ?? res instead of multi-branch if/else.
• Always wrap single-statement control-flow bodies in braces (if (!x) { return false }) to match the project’s curly lint rule; don’t rely on single-line if statements.
• Avoid introducing unnecessary async IIFEs or wrapper functions just to scope a few lines — restructure with early returns/switch blocks instead.
• When the same block of logic (e.g. building a response/headers) is duplicated more than once in a file, extract it into a single named helper function rather than copy-pasting.
• Favor simpler, well-known patterns for transformations (e.g. a single regex for camelCase→kebab-case conversion) over hand-rolled multi-branch logic, when they are equally correct and more readable.
• When combining &&/|| in a single condition, use parentheses to make operator precedence and intent explicit, e.g. contentType !== null && (contentType.startsWith('a') || contentType.startsWith('b')).
• Keep statement-termination style (semicolons vs. ASI) consistent with the rest of the file/codebase; if the codebase omits semicolons, use a leading ; only when required to disambiguate a new statement.

The goal is code that a reviewer can scan quickly: no redundant boilerplate, no accidental ambiguity from operator precedence or missing braces, and no duplicated logic scattered across a file.

This site is open source. Improve this page.