[bmitc]

It’s an unfortunate compromise with code formatters. As someone who takes code formatting really serious and puts a lot of manual thought into code formatting, code formatters almost always make my code worse, in my opinion, or at best unchanged outside of small errors like double spaces, etc. But it creates a standard that it loves everyone’s code towards, which is good., and also obviously alleviates the chore of manually formatting.

I just wish sometimes they were more configurable. For example, the Elixir formatter is quite opinionated on things but is generally not configurable.

[JshWright]

I often wish they were _less_ configurable. Even Black's handful of config options are too many... Each one is a chance to pick a whole new color for the bikeshed.

[bmitc]

That makes sense, but it's a problem when the formatter makes a rather opinionated choice and doesn't allow one to configure it. The primary example I'm thinking of in Elixir is comments for pipelines.

For example, if I use the pipe example on Elixir's landing page and add comments to it (obviously a contrived example):

    "Elixir"              # string to get frequencies for
    |> String.graphemes() # Get all graphemes (i.e., character units)
    |> Enum.frequencies() # Get the number of occurrences of each grapheme

This gets formatted by the Elixir formatter to:

    # string to get frequencies for
    "Elixir"
    # Get all graphemes (i.e., character units)
    |> String.graphemes()
    # Get the number of occurrences of each grapheme
    |> Enum.frequencies()

This is a rather strongly opinionated format stance, and as far as I know, it's not configurable.