Swift Formatting Guidelines

#41

Why couldn't "they" just not use the formatter in the first place?

(Félix Fischer) #42

Because the format doesn't suit the way they work, or the way they like seeing the code be presented to them

#43

So this highlights a fundamental difference between formatting goals:

One is to format your code so that others can understand it,
and the other is to format others' code to your preferences.

gofmt falls squarely in the former camp.

2 Likes
(Pedro José Pereira Vieito) #44

+1 to having a common style guide and something like Go's gofmt and Python's pep8.

1 Like
(Georgios Moschovitis) #45

Totally agree! I would love to have something like gofmt, even if the default formatting rules don't align with my preferences. Uniformity is more important.

2 Likes
(Jon Shier) #46

I, too, would like official tooling for formatting Swift code. But you all have to remember we're talking about a company which still hasn't built a formatter into their IDE after 20 years! That, despite having a rough version of one in clang-format and users having built a plugin that ties the two together. Still nothing. It's really quite ridiculous. Frankly, swiftlint and swiftformat should both have official equivalents, supported and extensible, and integrated into Xcode as well as available for other editors. Googling a bit, it seems like the beginnings of a tool (swift-format) exist, but it seems abandoned. In fact, you can try to invoke it but it fails:

jshier$ swift format
error: unable to invoke subcommand: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift-format (No such file or directory)

It's critical for Swift's adoption that these tools exist, so hopefully we'll see something (perhaps using libSyntax?) official and usable soon.

1 Like
(Jon Shier) #47

Looks like there has been some progress fleshing out libSyntax and integrating it into the compiler to a point where it's suitable for syntax highlighting (see this WIP PR), which would be fantastic if it's better than the current flickery, crashing mess. However, since it's still integrated into the compiler it still seems like it will susceptible to the same crashes as before, which is unfortunate. But at least there's some hope of real tooling coming out of this.

(Félix Fischer) #48

I agree with you. But also, bear in mind that @harlanhaskins is going to be working on (or is, maybe, idk the timelines here) swift-format for the Google SoC :slight_smile:

(Harlan Haskins) #49

Hi! swift-format is not a GSoC project, it’s just a Google project. We hope to have it up and released for testing in the near future. Stay tuned!

13 Likes
(Félix Fischer) #50

Ohhh. Gomen gomen, I mixed it up.

Good luck with that, and thanks for working on it ^^

(Pedro José Pereira Vieito) #51

Great news! The idea is to integrate and package it with the Swift releases in the apple/swift repo or distribute it as an independent tool?

1 Like
(JP Simard) #52

I'm thrilled that folks are working on alternative Swift formatters to SwiftLint's built-in formatting (aka rule correcting) functionality. That being said, there are many opportunities to enhance SwiftLint's capabilities towards this so I hope that those are also being considered rather than starting a new project.

Some opportunities to enhance SwiftLint could be to leverage SwiftSyntax on platforms where it's available to provide either new auto-correcting formatting rules or add alternative implementations to existing rules that could be either faster or more accurate.

There are many advantages to doing so within the existing context that SwiftLint provides, including the already established YAML configuration pipeline & machinery to run all the rules.

I'm happy to guide contributors who'd be interested in taking on some tasks along these lines.

1 Like