Is it better to run format before lint?

[jamesmyatt]

There are various ruff lint rules that are automatically fixed by ruff format, such as extra whitespace (W291) or semicolons (E703). Hence, is it better to recommend running the formatting hook before the linting hook, when using both?

[woctezuma]

When running with --fix, Ruff's lint hook should be placed before Ruff's formatter hook, and
before Black, isort, and other formatting tools, as Ruff's fix behavior can output code changes
that require reformatting.

When running without --fix, Ruff's formatter hook can be placed before or after Ruff's lint hook.

(As long as your Ruff configuration avoids any linter-formatter incompatibilities,
ruff format should never introduce new lint errors, so it's safe to run Ruff's format hook after
ruff check --fix.)

Reference: https://github.com/astral-sh/ruff-pre-commit/blob/main/README.md

[jamesmyatt]

Thanks @woctezuma . I suppose my question is whether, in the "without --fix" case, it's better to recommend that format be run first, because some of the formatting fixes will avoid linter errors, rather than to just say it "can be placed before or after".

[MichaReiser]

@jamesmyatt In the case where you don't use --fix I think it does make sense to run format before lint if you have some pycodestyle rules enabled. However, our general recommendation is to disable any formatting related lint rules if you use the formatter because they don't need to run, the formatter guarantees consistent formatting.

[jamesmyatt]

Thanks @MichaReiser . That makes sense. Is there a list of those?

[MichaReiser]

I don't think so. We should probably add one. We plan to have an entire category for formatting related lint rules which should make this easier in the future.

For now, it's mainly the pycodestyle rules (E1, E2, and E3)

[Mathieson]

I'm finding the linter reports incorrect lines for issues when run before the formatter, which makes sense considering the formatter might break up a single line into multiple, changing the composition of the file. The incorrect lines adds extra effort when tracking down the reported issues to fix them.

The line numbers are correct when the linter runs after the formatter.

[AHJiapengZhang]

I have a question here. Why do we have two tools linter and formatter separately? Would it not be sufficient to use ruff with the -fix option to enforce all rules and formatting requirements? Additionally, are there any scenarios in which ruff fails to address certain issues, necessitating a subsequent run of a formatter? Is this separation of responsibilities a common pattern among other linter frameworks?

[Avasam]

@AHJiapengZhang you can follow and upvote astral-sh/ruff#8232 for a unified command

[ssbarnea]

@AHJiapengZhang you can follow and upvote astral-sh/ruff#8232 for a unified command

See #120 which is about adding this unified hook before we have an unified command in ruff itself.

[user27182]

I'm finding the linter reports incorrect lines for issues when run before the formatter, which makes sense considering the formatter might break up a single line into multiple, changing the composition of the file. The incorrect lines adds extra effort when tracking down the reported issues to fix them.

The line numbers are correct when the linter runs after the formatter.

I think this is one of the key reasons to run format before check. The other is to avoid false positives, e.g. a line may be too long before formatting, causing check to emit an E501 error, but then after format runs the line may no longer be too long, and hence the error was already fixed by format. In this case an error is reported (with the wrong line number being referenced) but no action needs to be taken since there is no longer an error.... so why even show an error at all? This false-positive behavior leads me to routinely run pre-commit twice in quick succession to remove the noise.

To resolve this issue, can we swap the order of check and format in the repo so that format runs before check, and update the README to document to users that this order should be preferred?