code-style
Code Style
Make new or changed code indistinguishable from code a long-time maintainer of this project would have written. The goal is that a reviewer reading the diff cannot tell which lines are new based on style alone.
The one principle that matters
Match the project's actual conventions — as evidenced by its own code and config — not your own preferences or generic "best practices."
This is the trap to avoid. A project might use patterns you'd personally write differently: 4-space indent, no semicolons, require() over ESM imports, terse names, no JSDoc, a particular import order. Your job is to make the new code look like its neighbors, even when that means writing code you wouldn't choose on a blank slate. "Cleaner" is not the goal; consistent with this repo is the goal.
Two hard boundaries that keep this safe and reviewable:
- Style only — never change behavior. Naming is style, and it's where blending in is most visible. Renaming a local variable or a private/callback parameter to fit the project's conventions — casing and descriptiveness — is safe and expected: if neighbors spell names out, don't leave terse
a/b/xin the new code just because it reads fine to you. Be careful with public/exported symbols: renaming an exported identifier — or a public function's parameter, which callers may pass by keyword (e.g. Python kwargs) or rely on via reflection/codegen — can break callers. Only rename those when the symbol is brand-new and unreferenced, and call it out. Anything that changes what the code does (reordering arguments, changing a default, restructuring logic) is out of scope. When in doubt whether a change is behavior-preserving, leave it. - Surgical — only touch the changed code. Align the lines in the diff (and what's needed to make them consistent). Do not reformat, rename, or "fix" pre-existing code outside the change, even if it's inconsistent. That would bury the real change in noise and is exactly what reviewers hate.