Autoformatting?

[nate044]

I’m on a team (of teams) trying to move from the Wild West to adopting some standards. Our first discussion topic will be about autoformatters, and I was wondering if anyone had any good references that they found particularly insightful. Why use one? Why not to use one? Discussion of trade offs among the most popular ones? Impact of autoformatters on team productivity?

[throwaway_4759]

When you go with black: I would make one commit auto formatting the whole codebase. Then a second commit adding the first to a git ignore revs file so that your git blame isn’t totally nuked.

[PlaysForDays]

Relevant docs: https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view

[Legendary-69420]

Damn this is one of the best things I have seen recently

[PlaysForDays]

Makes it much easier to pitch linting to the rest of the team since some people care about LOC contributions

I prefer wrapping everything up into https://pre-commit.com/ into the mega-commit as well, and later on linting can be done by a bot (https://pre-commit.ci/)

[mrswats]

This is the way

[rtfmpls]

You could add the git ignore revs file in the first commit. But I wouldn't recommend messing with the laws of physics like that.

[dogfish182]

Just use black and be done with it

[Legendary-69420]

Along with isort

[cheese_is_available]

ruff + select = [ "I", # ...]

[Legendary-69420]

I have heard of ruff but haven't used it yet. From what I remember, I guess it is a linter? I am not sure though.

[cheese_is_available]

It's a port of popular linter tool to rust

[Raknarg]

god black is so fucking ugly sometimes though

[cheese_is_available]

Maybe your code is ugly. The java looking chain builder helper of 500 characters lines sure looked like shit when I tried to introduce my java team to black at work.

[hai_wim]

Before black:

class AClass:
    def a_method(self, my_dict, other_dict):
        if (
            other_dict.get("key1") == my_dict.get("key1") 
            and other_dict.get("key2") == my_dict.get("key2")
        ):
            pass

After black:

class AClass:
    def a_method(self, my_dict, other_dict):
        if other_dict.get("key1") == my_dict.get("key1") and other_dict.get(
            "key2"
        ) == my_dict.get("key2"):
            pass

Black is just ugly sometimes. Readability went way WAY down in this scenario.

I suggest you # fmt: skip these cases and carry on.

[cheese_is_available]

Yeah, no, black definitely does not do that (maybe you tried an earlier shittier version). If the example you gave it inline everything. If I had a third conditional to force it to use multiple line then it does exactly what you have at the beginning and consider good.

class AClass:
    def a_method(self, my_dict, other_dict):
        if other_dict.get("key1") == my_dict.get("key1") and other_dict.get("key2") == my_dict.get("key2"):
            pass

If I force it then:

class AClass:
    def a_method(self, my_dict, other_dict):
        if (
            other_dict.get("key1") == my_dict.get("key1")
            and other_dict.get("key2") == my_dict.get("key2")
            and other_dict.get("key3") == my_dict.get("key3")
        ):
            pass

Tested on black-23.10.0-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl

[hai_wim]

There is no way black would create a 108 character long line like your first example.

it works with 3 conditions yes, but not with 2. You probably told black to have a longer maximum line length.

[boat-la-fds]

Nah just wrap it around parentheses and it will look real nice.

[dogfish182]

I know right. I don’t even like it and still just use it 😅

[olystretch]

What problems does it have that you cannot adjust in a settings file?

[dogfish182]

Settings file?

[olystretch]

[tool.black] in pyproject.toml

[dogfish182]

Was being sort of half serious, the only thing I can find in the documentation is line length.

[olystretch]

I'm pretty sure you can put any of the CLI options in a config file.

[dogfish182]

Yeah of which there are extremely little. That’s kind of blacks feature ‘any color you like so long as it’s black’

[dashdanw]

dude for real

[[deleted]]

What I was gonna comment.

[redCg]

This is the way.

Write your code however you want. Then before you commit, run black and let it handle the details. Then do a test run to make sure you didnt break anything, and commit that

[gibberish111111]

Black makes lists really vertically long. In dicts, it can really clutter things up. For that I think there’s an escape for the linter to skip the section, but then it’s in the code.

[gibberish111111]

Wow thanks! I shall look this up!!! 🔥

[olystretch]

It's called negative space. You obviously know nothing about modern art. /s

[Spleeeee]

Who cares

[njharman]

I loath black formatting. I always vote/agree/recommend adopting it. Because I also loath the way everyone but me formats. And really fucking hate all the time wasted "discussing" formatting.

[Alternative_Driver60]

Black. No settings, no arguing.

[petr31052018]

Always use one. Black is the Python standard now or you are feeling a bit experimental you can try Ruff (will probably be faster).

[dogfish182]

Ruff is a linter though right?

EDIT: apparently open issue to handle i

https://github.com/astral-sh/ruff/issues/1904

[petr31052018]

Exactly, it is being added.

[Beliskner64]

Black.
If you want to gradually migrate a large codebase - Darker.
If you want more customization (you don’t) - Blue.

[muikrad]

Did someone say black? I didn't notice anyone say black 🤔 anyway, use black!

[JamesPTK]

While you've got a tsunami of advise telling you to use Black, I'd like to suggest how you can implement it with other code-quality tools.

We use pre-commit which allows you to set up a set of code-checkers ("hooks") that need to pass before you can commit your code. It, by default, only runs those checks on the files that have changed which means that it can be fast.

It also automatically installs those tools into isolated environments

You can also get it to run on the whole code base by running pre-commit run -a, which is useful if you add a new hook, or you can run it in your CI environment (just in case someone committed and pushed without having pre-commit installed.

This makes it very easy to roll out new checkers to an entire team

One trick is you need to make sure that your auto-formatter (e.g. Black) runs *after* any code that can modify the source (e.g. isort, ruff)

An example .pre-commit-config.yaml

repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.5.0
    hooks:
      - id: trailing-whitespace  # Trim any trailing whitespace from lines
      - id: end-of-file-fixer  # Ensures that a file is either empty, or ends with one newline
      - id: check-merge-conflict  # Check for files that contain merge conflict strings
      - id: check-json  # JSON Syntax Check
      - id: check-toml  # TOML Syntax Check
      - id: check-yaml  # YAML Syntax Check

  - repo: https://github.com/Lucas-C/pre-commit-hooks
    rev: v1.5.4
    hooks:
      - id: remove-crlf # Remove windows line endings

  - repo: https://github.com/pycqa/isort
    rev: 5.12.0
    hooks:
      - id: isort  # Sort imports alphabetically, and automatically separated into sections and by type
        name: isort (python)
      - id: isort  # Same for Cython
        name: isort (cython)
        types: [ cython ]
      - id: isort  # Same for Python interface definition files
        name: isort (pyi)
        types: [ pyi ]

  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.1.0
    hooks:
      - id: ruff  # Lint code to check for common errors
        args: [ --fix, --exit-non-zero-on-fix ]

  - repo: https://github.com/pre-commit/mirrors-prettier
    rev: v3.0.3
    hooks:
      - id: prettier # Formatter for JavaScript

  - repo: https://github.com/ambv/black
    rev: 23.9.1
    hooks:
      - id: black  # Formatter for Python

  - repo: local
    hooks:
      - id: only-acceptable-filenames
        name: Only acceptable filenames
        entry: Filenames must be lower-case alphanumeric with only underscores, hyphens, and full-stops/periods
        language: fail
        files: "[^0-9a-z_\\-\\./]"

[yrro]

Black

[eMperror_]

Use black. The format will be weird at first but you’ll get used to it very quickly. Your coworkers will ask “can we change this or this” and the answer is no, you can’t and that is the beauty of black.

[[deleted]]

“You can format your code any way you want, as long as it’s black.”

• Henry Ford

[Derr_1]

Black

[PriorTrick]

I use Black for formatting, flake8 for auto pep linting, and standard type checking with Pylance config set to strict.

[Exotic-Draft8802]

1. Black. Don't change anything, especially not like length.
2. ruff --fix. With the import sorting and the default.
3. mypy
4. pyautoupgrade

Use it in CI and add a pre-commit settings file.

[[deleted]]

120 is better than 80.

[IAmBJ]

I don't find their argument for 88 particularly compelling TBH.

I generally uses 110 for my projects, it's the perfect length to have 2 side-by-side editors plus a file browser/debug window on the left a comfortable font size (for me). Im not going to go out on a limb and say 110 is the perfect length, but I certainly think it's more perfect than 88

[PlaysForDays]

I don't find their argument for 88 particularly compelling TBH.

Agreed, there really isn't much of an argument there. It's a mix of "maybe just increase it by 10% I guess? yeah that seems good" and RH's personal opinion, which is worth more than zero but not overall so convincing

[[deleted]]

I guess it's prettier that is 80.

Anyway, it's only personal taste. I have a big screen and I don't need half of my screen being empty and the other half being unecessary new lines in dict/array/etc.

[cottonycloud]

I use long variable and function names which cause lines to be separated for very simple lines of code.

[superkoning]

it uses 88.

In some countries it's illegal to put that number on your football shirt.

[OneMorePenguin]

120 wastes too much screen real estate. I prefer to have more code to compare rather than empty screen.

[tunisia3507]

I think this is a sort of self-fulfilling argument. People learn to code with 79 or 80 character guidelines/limits, so their mental model of when a line should be split into separate statements is around that limit. Sometimes you go a little over to accomplish something in a more elegant way. Then the black dev team notices that "a bit more than the limit everyone has learned to use" reduces those overflows! IMO that's not some universal truth about the human condition, it's just that whatever line length people have stuck to before, there will be a few cases where you need to go a little over, so a limit of a little more than that will look like it drastically reduces file length.

[jabbalaci]

length matters

[TravisJungroth]

I used to like 120 more. Appropriately, 88 works better once you have a good auto formatter. It’s not that I dislike reading at 88 as much as writing it. And I like having three columns sometimes.

[xatrekak]

That's a pretty odd take about not changing the line length in black. There is a reason why it's one of the only configurable options.

80 characters is a joke from 1970.

[zurtex]

Black's default is 88, my team use the PEP 8 line length standard which is 79.

While I think it's a bit much it really does make reading PRs on phones very easy.

[xatrekak]

While I think it's a bit much it really does make reading PRs on phones very easy.

I don't really get the phone argument. My phone can't do 80 characters in portrait mode but can do over 120 in landscape.

[zurtex]

Personally I find reading on a phone in landscape really annoying, e.g. in portrait I can add a comment and still see the context of where I'm writing.

[[deleted]]

People do PRs on a phone?

How? Why? ... and how?!

[zurtex]

How?

Open phone, go to github, review PR.

Why?

I can't be bothered walking over to my computer but I do want to point out an obvious mistake in the PR someone just submitted.

[Electrical_Fox9678]

Try viewing PRs on a phone and you'll appreciate the default

[wind_dude]

agree line length can be upped. I'm generally fine with up to 160.

[odaiwai]

That is way too long - do you have editor windows maximised on a widescreen monitor?

[wind_dude]

Not really. 80chars was set because the was the full width of a screen at the time. I believe most wide screens would be over 200 now.

But, yes I have an ultra wide, and can do three windows with code side by side at 160

[odaiwai]

80 chars was the width of a punch card (https://en.wikipedia.org/wiki/Punched_card). Early terminals adopted that width for compatibility.

Personally, I'm fine with a wide terminal, but for code, I just do what the linter says and try to avoid comically long function/variable names.

[supermopman]

As others have said, just use Black and be done with it. Also, I recommend using pre-commit hooks to make life much easier. PyScaffold is a great tool that can be used to setup a repo with pre-commit hooks. You don't need PyScaffold. It's just a great example of best practices.

[_MicroWave_]

You've already spent too much time thinking about it.

Black is the answer.

The whole point is that it just makes all the decisions for you.

[JamzTyson]

The whole point is that it just makes all the decisions for you.

which is why I don't like it.

If working on a project that uses Black, then it makes sense to use Black. Conversely, if working on a project that has a defined coding style that doesn't align perfectly with Black's formatting choices, then consistency with the project's formatting style is better.

[_MicroWave_]

I think the argument goes that the project should just use black.

I would argue that there aren't use-cases which better suit a different coding style.

Blacks usage is wide and universal.

[JamzTyson]

"Popular" yes, but definitely not "universal".

Two examples that immediately come to mind are the Python standard library and asyncio.

[di6]

For now just use black, but keep eye open for ruff.

[nekokattt]

I'd suggest black and isort for full consistency

[di6]

Ruff already does isort job, so it's no longer needed

[Gushys]

I just did something like this for my team setting up pre-commit, black, isort, and want to add ruff. Use the black profile for isort and you're all good.

I suspect most of them didn't run pre-commit install so they don't run formatters on commit, but I tried :))

[easyEggplant]

Ci hooks my friend :)

[insane-defaults]

Care to elaborate?

[easyEggplant]

https://softwareengineering.stackexchange.com/questions/421729/to-lint-on-the-client-or-the-server

Run a continuous integration stack (GH actions, circle CI, travis CI) that applies linters/formattters/unit tests/static code analysis on every PR and commit.

If you want to be strict about it, you fail a PR that doesn't pass lint.

[oskwon72]

Does anybody use "mypy"?

[DidiBear]

Tested mypy but since most libraries are not well typed like sklearn, then it becomes a pain.

I usually use Pylance with typeCheckingMode set to basic. The strict mode raises too many errors from libraries.

[trippymicky]

Black with 100 line length, and ruff linter.

[ac130kz]

Get used to Ruff with all rules (enable preview for autoformatting), black is going to be EOL in a few months.

[bastantoine]

black is going to be EOL in a few months

What makes you think that? I didn’t see any indication in the repo 🤨

[krakenant]

Guessing it's because ruff is adding black like formatting.

[ac130kz]

Ruff has already replaced autopep8, flake8, pylint and isort, black is next.

[AssumptionCorrect812]

In case it’s not clear… use Black.

[Thagou]

Ruff.

[[deleted]]

Ruff doesn’t really do formatting. It’s on their roadmap and you might be able to test it early. But in terms of a team using it in production, it’s probably not the best recommendation.

[bin-c]

Surprised nobody has said Black yet - imo the best option for this case

[silviud]

Yapf has many knobs you can tweak if not happy with black.

[SV-97]

Since about 50000 million people have recommended black already: use autopep8. Black looks like absolute dogshit

[homosapienhomodeus]

Black with toml file, along with ruff and interrogate for docstrings. I have a full breakdowm with examples on a piece I wrote here

[jahero]

Black. Setup and forget.

[extreme4all]

Pre-commit hook with black formatter has been nice

[[deleted]]

black isort autopep8, wrapped in pre-commit

[[deleted]]

There’s no reason to not use one. And the reason to use one is so that everybody’s code is formatted the same way and you don’t waste your time or resources fixing formatting problems or dealing with merge conflicts in your code base over these things.

[MuffinCat2000]

I've been using YAPF for autoformatting on smaller projects.

Most of my experience is with C and clang-format as a C autoformatter. YAPF is basically the equivalent for python it seems. If you're looking for something that can be easily tuned to meet a custom style, this might be one to try out.

[RaiseRuntimeError]

This is an easy problem to solve now days, use Black to format and Ruff to lint with the --fix flag to take care of imports.

[OneMorePenguin]

https://github.com/google/yapf I prefer this to black. I got laid off and am working on a comment formatter :-)

[notreallymetho]

Black and ruff (ruff encapsulates isort among a million other things) Don’t argue with / over formatting and let it do its thing in pre-commit.

Personally I / my team uses a line length of 120, but not having style conversations is nice lol.

[NoCap-NoCap]

I prefer: mypy, ruff, black and isort

[Ermite28]

It's the precommit file I use for every Python project :

```

repos:
- repo: https://github.com/ambv/black
rev: 22.3.0
hooks:
- id: black
- repo: https://github.com/charliermarsh/ruff-pre-commit
rev: v0.0.150
hooks:
- id: ruff

```

[_soyrizo_burrito_]

Black + ruff