ruff-pre-commit icon indicating copy to clipboard operation
ruff-pre-commit copied to clipboard

Is it better to run format before lint?

Open jamesmyatt opened this issue 1 year ago • 9 comments

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?

jamesmyatt avatar Mar 13 '24 15:03 jamesmyatt

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

woctezuma avatar Mar 13 '24 20:03 woctezuma

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".

jamesmyatt avatar Mar 13 '24 22:03 jamesmyatt

@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.

MichaReiser avatar Mar 18 '24 11:03 MichaReiser

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

jamesmyatt avatar Mar 18 '24 11:03 jamesmyatt

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)

MichaReiser avatar Mar 18 '24 13:03 MichaReiser

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.

Mathieson avatar Apr 25 '24 05:04 Mathieson

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?

AHJiapengZhang avatar Jul 04 '24 14:07 AHJiapengZhang

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

Avasam avatar Jul 05 '24 14:07 Avasam