Pitch: an Official Style Guide and Formatter for Swift

(Shai Mishali) #21

Overall +1
I think I'd like to see SwiftLint as another option for enforcing some sort of a unified style guide. I'm not sure what specific benefits Google's tool brings to the table, plus I'm not sure it would be advisable to commit Swift users to use some 3rd party tool in that sense.

In the general consensus, Style Guides are great. As @mergesort mentioned, the Go community gained quite a lot from gofmt. With that, there are also different preferences for some developers and teams, so there should be great tooling to allow for this flexibility.

On the back of my head, I'm worried enforcing a style guide is a bit too robotic for all Swift developers. And I'm worried about cases where the formatting suggested by Google/Apple will be dissatisfactory. Like happens many times when using "Auto Format / Auto Indent" inside Xcode and getting sub-optimal results.

So, overall +1, with some worries :)

(Joe Groff) #22

One great benefit to having a single approved style is that it makes automated refactoring, migration, and other code transformation tools much, much simpler when they can assume the official style without having to tolerate and attempt to maintain (and be tested with!) every possible local variation of style. I want to believe we can pull this off for Swift.

(Tony Allevato) #23

Just to clarify this point, we intend to propose that swift-format ("Google's tool") become part of the Swift project, as it has been a collaborative effort thus far between us and the Swift team. It would not be a third-party tool at that point.

(Marcelo Fabri) #24

That means that the official style would be strictly enforced (otherwise tools would not work properly).

This seems a bad idea from a user point of view.

(Dave DeLong) #25

• Should Swift have a built-in formatter → yes, 10,000 times yes
• Should Swift have an official, recommended style → yes
• Should the official Swift style be the only support style → no

This may be a bit "get off my lawn"-level of curmudeoning but I have a few personal style things I do while programming that I find constantly fly in the face of auto-formatters.

During my time using go to write the backend for one of my apps, I mostly loved how go-fmt was part of the process; for someone who was new to go, it was great to have things auto-change to what was "recommended".

Again, for being new to the language, it was great.

However, I was not new to programming, and I tried to bring over some of my personal style choices as well, such as single-line if statements for trivial checks + trivial exists:

if someCondition { return }

It was exceptionally frustrating that these were constantly being turned in to:

if someCondition {

So, I'm in favor of having an auto-formatter. Just please make sure that I can tweak it and turn on or off things that I want.

What we want is readable code, and everyone tends to have slightly different definitions of what that means.

(Shai Mishali) #26

Clearer now, thanks for clarifying that point :)
In that case I have less worries about it. I'd still love to see how it goes face-to-face with more known community-based (and battle-tested) solutions such as SwiftLint, for example.

I remember a post by one of the SwiftLint team that tried to use SwiftSyntax to hopefully get rid of the SourceKitten dependency and was disappointed by how slow and non-performing it was. I'm absolutely not saying this is the case with swiftformat, but I'd definitely love to see a more aggressive comparison/testing effort before the community, and the language, commits to any single tooling.

(Joe Groff) #27

Tools ought to accept any valid Swift code in any format, but they don't need to guarantee to preserve nonstandard formats. The latter is the bigger challenge, and becomes exponentially harder with more complicated transformations.

(Shai Mishali) #28

I think the point is that the customizability level has to be very high for this to be fitting for the Swift community. I think @davedelong's comment illustrates my personal thoughts best on this matter :)

(Marcelo Fabri) #29

Thanks for the clarification. I thought it would only accept the official format.

(Tony Allevato) #30

This is exactly the case that swift-format's respectsExistingLineBreaks configuration setting handles. If that setting is false, the formatter will aggressively try to fit blocks that can fit onto one line onto one line. If the setting is true, then we give the user more flexibility to add their own discretionary line breaks where it improves readability for them, as long as those line breaks don't create some other violation of the (yet-to-be-ratified) style.

Part of this whole process will be determining from the community exactly which knobs they think are valuable, so this is the kind of feedback we're looking for.

(Dave DeLong) #31

(This is a separate reply because it's a separate thought)

If we allow for overridable style guides, let's please learn from LLDB's mistake* and allow ourselves to have per-folder, per-project, and per-user styles.

For example, in a project, the formatter should consult, in order:

  • a style file placed in the same folder as the file being stylized. This allows for the case when you have a large monorepo, and different teams work in different sub-folders
  • a style file placed in the root of the project. This allows for a per-project style guide. For example, a contracting agency might have specific style requirements they're supposed to follow for a particular project
  • a style placed in the user's home folder. This allows for a solo developer to define a single ~/.swiftstyle.fmt (or whatever) file that captures his or her unique style, thus saving him/her from having to re-define it everywhere
  • the final, system fallback style defined by the compiler/SDK

*LLDB's mistake is that you can't have per-project .lldbinit files, which means you can't ship debugging tools that are unique to a particular project. This is a long-standing open issue with LLDB and frankly I'm pretty amazed it's never been addressed.

(Tony Allevato) #32

swift-format can do this today (see the Configuration section of the readme). It scans the directory containing the source file first, then upward through parent directories until it finds one, or doesn't and falls back to a default config.

Tweaking that logic to include other search heuristics, like user home directory, would certainly be a reasonable thing to consider.

(Adrian Zubarev) #33

I second this. There is a lot good feedback already in this thread. I would like to add that it would be amazing if we could have a project style and a local style. By that I mean that the IDE should format the code with your local style when viewed but save everything in the project style. So if you'd open the swift file in a text editor it will present the code in the project style, while the IDE will display a different formatting style with your local preferences.

And whatever the result will look like, please make any tooling that originated from this thread written in Swift and extensible, so more community members that are most familiar with Swift than other languages can contribute better. ;)

(Tony Allevato) #34

This idea is mentioned in "Alternatives Considered" above, but my view is that it's beyond the scope of what even can be proposed for the Swift project, because it relies on either specific IDEs
or source control systems to implement what you describe.

Nothing about what we're intending to propose would preclude someone from using a workflow like this, but it's not something that the Swift project can provide in isolation.

(Argyrios Kyrtzidis) #35

To clarify, this was trying out swift-4.2-branch version which only supported invoking swiftc for parsing. There's a faster way in swift-5.0-branch by calling into sourcekitd, and swift-5.1-branch is even much faster due to changes I first outlined here.

(Boris Triebel) #36

For: Powerful and configurable and convenient to use formatting tools.
Against: A single blessed style to rule them all.

(Shai Mishali) #37

That's awesome news! Thanks!

(Diogo Tridapalli) #38

Dave's comment expressed exacly what I think.

(Pedro José Pereira Vieito) #39


Yes, I think it is very important for the Swift community to have a standard style and the tooling required to enforce and define it.

(Adrian Zubarev) #40

Maybe I'm just thinking out loud, but if the tooling we are talking about is potentially fast enough restructuring a single or multiple files that are tokenized, wouldn't it be just a consequence of this whole project? I mean even if it was a CLI you'd execute a configuration to format cached code with local style and when saving you can pick the project style. The tooling itself does not require IDE support, it just needs to be designed so it can quickly reformat the code with a different style when requested.

To be clear, it's not a dealbreaker for me, but something along the lines would be awesome.