psf/black

Gradual adoption: option to only format PEP8 errors

max-sixty opened this issue · 7 comments

max-sixty commented

If I were starting a project from scratch, I'd start with enforcing black. But most code is written on existing projects, and converting everything to black requires a high degree of confidence and share of agreement within contributors.

What do you think about enabling an option in black to reformat only:

  • Code that violates PEP8 / some rules
  • Code that has been changed

One of the nice attributes of autopep8 is that it only changes code where there's a problem. This has two big advantages to adoption:

  • The impact is limited to strict, unambiguous improvements
  • Projects don't require everyone to agree that autopep8 is the correct tool - an individual / subset can start using it for their contributions

Thanks again for the project

ambv commented

Black by design doesn't enable reformatting parts of the file. This functionality is against PEP 8 which states that internal consistency within the file is more important than any particular style. If you used Black for this purpose and somebody else kept using autopep8 or YAPF, your styles would fight with each other.

Black is both a tool and a code style. You are adopting the style. The tool is merely an automated way of enforcing it. Yes, this requires agreement within your project that this is the style your team wants to enforce. If you decide that you don't like the particular style and you'd rather keep formatting by hand instead, that's fine by me. If you decide that the style is fine but the tool is not stable enough yet, hopefully this will be gradually resolved by increased adoption of the tool and squashing bugs one by one.

As far as responding to particular pycodestyle violations and only formatting that code, I fully agree with YAPF's take on it which is that this is a suboptimal strategy. It also famously leads to situations where one fix may introduce other pycodestyle violations.

Summing up, this is deliberately not in scope for this project.

  • 👍12
  • 👎18
  • 😕1
max-sixty commented

OK, thanks for the full response!

  • 👍3
DylanYoung commented

I don't think that's how time works.... It's continuous, not discrete ;)

akaihola commented

The darker tool applies Black formatting only to lines which have changed in the Git working tree since the last commit.

  • 👍4
pauloneves commented

Sure the formatting consistency in the file is important and black shouldn't fight with other formatters. My use case is different. My coworkers didn't use any formatter. I persuaded the team to use black as standard formatter, but we have a lot of already written code.

When I'm fixing a bug or adding a feature, I'd like to use black in the new code. I can't reformat all the file because it would display my name when someone uses the git blame command. Who edited a line of code is a very important info for developing software. Without partial formatting, black is useless for already existing code base.

  • 👍4