The default formatting configuration and workflow are strange

[audio-engineer]

First of all, I love the idea of swift-fromat. I love opinionated and official tools, and I really believe that Swift needs something that is like Prettier for JavaScript/TypeScript, Black for Python, or Google's Checkstyle style for Java: Opinionated, beautiful and effective formatting, easy to set up, can be invoked from an IDE or CLI, etc.

Having said that, I find the default, opinionated configuration of swift-format puzzling and chaotic to say the least.

I mean, how is this (formatted with the default swift-format configuration and respectsExistingLineBreaks: false) better

...
          }.contentShape(Rectangle()).onTapGesture { currencyStore.toggleSelection(for: currency) }
            .listRowBackground(currency.isSelected ? Color.gray.opacity(0.2) : Color.clear)
        }.refreshable { currencyStore.fetchCurrencies() }.navigationTitle("Select Currencies")
          .toolbar {
...

than this (formatted manually)

...
          }
          .contentShape(Rectangle())
          .onTapGesture {
            currencyStore.toggleSelection(for: currency)
          }
          .listRowBackground(currency.isSelected ? Color.gray.opacity(0.2) : Color.clear)
        }
        .refreshable {
          currencyStore.fetchCurrencies()
        }
        .navigationTitle("Select Currencies")
        .toolbar {
...

?

In the first example, it's almost impossible to tell which modifier/method is chained to which closure or object. It's cluttered with too much information per line, and readers need to read horizontally, instead of vertically, and keep mental track of all the parentheses and braces in order to be able to tell what is chained to what.
The second example is much more readable, since the indentation level visually queues the reader. E.g., it's instantly obvious that refreshable, navigationTitle and toolbar are chained to the outer scope, not the inner. I am not saying that this formatting style is perfect, but it does at least make the code more readable for the given example.

This is just one of many examples I could show to support my point.

Now, I know you might say that I can just leave the respectsExistingLineBreaks option at the default true value, and then make sure I create the formatting pattern above manually while writing the code. But this fully defeats the purpose of an opinionated, deterministic formatter which should both always yield the same output formatting on a given input, and format to a understandable and readable style - without me having to change any configuration values. Also, it would require me to manually either write or read all of the source code myself (to add the desired line breaks, etc.). I wouldn't be able to rely on mass actions like running the CLI like swift-format format -ir . or some IDE action like Format all code in this directory. Leaving respectsExistingLineBreaks at true essentially gives each developer in a team the task and responsibility to format their code themselves, and personal inconsistencies create the formatting mess that we all hate. ...Which is just what swift-format should solve.

To sum up, swift-format should be more opinionated, and the default style should be more sensible - otherwise there is no point in using it for what it is.

[ahoppen]

Synced to Apple’s issue tracker as rdar://143821093