astral-sh / ruff-pre-commit

A pre-commit hook for Ruff.
Apache License 2.0
795 stars 38 forks source link

Is it better to run format before lint? #74

Open jamesmyatt opened 3 months ago

jamesmyatt commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

@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 commented 3 months ago

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

MichaReiser commented 3 months ago

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 commented 2 months ago

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 commented 3 days ago

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 commented 2 days ago

@AHJiapengZhang you can follow and upvote https://github.com/astral-sh/ruff/issues/8232 for a unified command