Format Snippets Before Asking for a Code Review

Before asking for a code review, run the formatter that the project already uses and inspect the resulting diff. Consistent indentation and line breaks help reviewers focus on logic, but a large formatting-only change can make it harder to see what the feature actually changed. If you are fixing a bug in one function, avoid reformatting unrelated files in the same commit. When a repository has a configuration file, use it rather than choosing personal preferences that may conflict with the team.

If the project does not have a formatter, agree on a simple configuration with collaborators before applying it to a large codebase. A dedicated formatting commit makes the change easier to review and allows future feature commits to stay focused. Include the formatter version or command in the project documentation so another developer can reproduce the same output. This reduces noisy diffs caused by different local settings.

Formatting is not a substitute for tests, linting, compilation, or security review. A neatly formatted function can still contain an incorrect condition, unsafe input handling, or a broken edge case. Run the checks appropriate to the language after formatting, and inspect any change involving string literals, comments, templates, or whitespace-sensitive syntax. If the formatter reports a parse error, resolve the syntax issue rather than assuming that the code is now validated.

When sharing a minimal reproduction or code sample, remove credentials, private URLs, and personal data before pasting it into a public formatter. Review the output for accidental changes and include the relevant language or file type where the tool asks for it. A formatter improves readability; the author and reviewer remain responsible for understanding what the code does.

For a review request, include the command or editor action used to format the code if the reviewer may need to reproduce it. Mention any files that were intentionally left untouched because their format is generated or whitespace-sensitive. This context helps reviewers distinguish expected formatting changes from accidental edits and keeps the discussion focused on the behaviour being changed. A tidy diff is useful only when its scope is clear. If a formatter runs automatically in continuous integration, note that check in the review description as well.