How to format JavaScript for a clearer code review

Key takeaways

Format before review so the diff highlights behavior instead of whitespace.
Use one shared formatter configuration and pin its version in the project.
Separate mechanical formatting from logic changes whenever possible.
Treat formatting as a repeatable team rule, not a reviewer preference.

A code review is easiest when every changed line deserves attention. In an unformatted file, reviewers spend time decoding indentation, wrapping, quote styles, and inconsistent braces before they can reason about behavior. A formatter removes that visual noise. It does not make the program correct, but it makes the important questions—data flow, error handling, naming, and edge cases—much easier to see.

The most useful formatting workflow is deliberately boring: agree on a configuration, run the same formatter everywhere, and avoid mixing a repository-wide reformat with a feature change. The JavaScript Formatter can help you inspect a small source sample, while your project configuration and automated checks should remain the final authority.

What formatting changes—and what it does not

Prettier describes its primary requirement as producing valid code with the same behavior as the input. It parses source into a syntax tree and prints that structure according to a consistent set of rules. This is fundamentally different from a collection of search-and-replace operations. A parser understands that a brace may start a block, that a slash may begin a regular expression, and that punctuation inside a string is data rather than syntax.

Formatting changes presentation: line breaks, indentation, spaces, quote choices where safe, trailing commas, and the way long expressions wrap. It should not redesign an algorithm, rename variables, reorder side effects, or remove apparently unused code. Those are refactoring or optimization tasks and deserve their own review. Keeping this boundary clear makes a formatting-only diff easy to approve and easy to revert.

The output can still look surprising. A formatter may expand a carefully arranged object or collapse a short expression because its printer makes decisions from syntax and configured width, not from the author’s manual alignment. That consistency is the benefit. When every contributor receives the same output, reviewers stop negotiating local style on every pull request.

A review-friendly formatting workflow

Start from a clean working tree. Commit or stash unrelated work before running a formatter across multiple files. This makes it possible to inspect exactly what the formatting command changed.
Confirm the parser. JavaScript, TypeScript, JSX, and JSON have overlapping syntax but different parsing rules. A formatter normally infers the parser from the filename; a browser tool needs an explicit choice or a sensible default.
Load the project configuration. Options such as print width, semicolons, single quotes, JSX quotes, and trailing commas should come from the repository. Personal editor settings should not silently override them.
Format the smallest sensible scope. For a feature branch, format the files you touched. A deliberate repository-wide migration should be a separate change with its own announcement and review strategy.
Inspect the diff, not only the rendered file. Look for changed string literals, comments moved away from the code they explain, parser errors, generated files, and unexpectedly large sections. Formatting should create a mechanical diff.
Run the project checks. Execute tests, type checking, linting, and the normal build. A formatter is designed to preserve behavior, but project checks catch an incorrect parser selection, a malformed original file, or a tool-version mismatch.
Commit formatting separately when practical. A standalone formatting commit lets reviewers hide or approve mechanical changes before examining the behavioral commit.

Example: turn dense source into reviewable source

Consider a valid but compressed function:

export function total(items,{taxRate=0}={}){if(!Array.isArray(items))throw new TypeError('items must be an array');return items.reduce((sum,item)=>sum+item.price*item.quantity,0)*(1+taxRate)}

A formatter can make the control flow visible:

export function total(items, { taxRate = 0 } = {}) {
  if (!Array.isArray(items)) {
    throw new TypeError("items must be an array");
  }

  return (
    items.reduce((sum, item) => sum + item.price * item.quantity, 0) *
    (1 + taxRate)
  );
}

The formatted version exposes several review questions. Can quantity be negative? Is price always a finite number? Should tax be rounded, and in which currency? Those questions existed before formatting, but the reviewer can now find them without first untangling the line.

Keep formatter changes out of behavioral commits

The most common formatting mistake is running a new version across the entire repository while also changing a feature. Even if every formatting change is correct, the resulting diff hides meaningful edits. Blame history becomes less useful, merge conflicts increase, and reviewers may approve a logic change because it is buried among thousands of mechanical lines.

If the team wants to adopt a formatter or update a major version, make that migration explicit. Pin the version, record the configuration, format the agreed scope, run the complete test suite, and merge it when other long-lived branches are quiet. Contributors can then rebase on a stable formatting baseline.

Generated and vendored files need a policy too. Formatting compiled bundles, lockfiles, snapshots, or copied third-party code can waste time and make later updates difficult. Use ignore files for content that has a different source of truth. Conversely, do not ignore ordinary source merely because it currently formats poorly; fix the underlying parser or configuration issue.

Configuration choices that actually matter

Print width is a wrapping target, not a hard maximum. Long URLs, strings, and indivisible identifiers can exceed it. Choose a value that works with the team’s typical split-screen review layout rather than chasing an exact character limit.

Line endings matter in cross-platform teams. A consistent LF policy prevents entire files from appearing changed when a contributor uses a different operating system. Quote and semicolon preferences have far less impact on correctness; their main value is removing recurring debate. Trailing commas can create cleaner line-based diffs when list items are added, but the configured language target must support the emitted syntax.

Avoid maintaining different rules in the command line, editor extension, CI job, and browser utility. The repository configuration should be the source of truth, with tools reading it whenever possible. Pinning the formatter version is equally important because printer output can change between releases even when configuration stays constant.

Review checklist

The formatter version and configuration match CI.
The correct parser was selected for JavaScript, JSX, TypeScript, or JSON.
Only intended source files changed.
Generated, vendored, and snapshot files follow the repository policy.
The diff contains presentation changes only, or behavioral changes are isolated.
Comments still describe the nearby code.
Tests, type checks, lint rules, and the production build pass.
The final commit is small enough for a reviewer to understand its purpose.

Frequently asked questions

Should formatting run automatically on save?

Usually yes, after the repository configuration is stable. Format-on-save gives immediate feedback and prevents large cleanup diffs. CI should still verify formatting because not every contributor uses the same editor, and automated changes may be produced outside an editor.

Can formatting break code?

A mature formatter is designed to preserve behavior, but no tool replaces verification. Choosing the wrong parser, feeding unsupported syntax, changing tool versions, or formatting code that depends on unusual automatic-semicolon-insertion behavior can expose problems. Review the diff and run the project checks.

Should reviewers comment on style after a formatter is adopted?

Reviewers should focus on readability issues the formatter cannot solve: misleading names, deeply nested logic, overly broad functions, and comments that explain what instead of why. Questions already decided by automated formatting should not consume review time.

Is an online formatter enough for a repository?

It is useful for a snippet, a learning exercise, or checking how an option affects output. A repository still needs a pinned dependency, shared configuration, ignore rules, editor integration, and CI enforcement. Use the browser result as a focused preview, then verify with the project’s own toolchain.