What are people using for code formatting?

I've gotten really used to Elixir having a true AST code formatter, and I appreciate Jet Brains Kotlin code formatter. I don't necessarily like the formatting options, but I'm frankly juggling enough languages these days, that I'm tired of trying to maintain some sort of sane hybrid approach. So I just want to let the tools format stuff and when in Rome, do the roman idiomatic thing.

I've found the swift-format project, but it looks not going places. I don't really care what the tool is. I'm just curious what tool + settings people are using. I may just use Ray Wenderlich's settings + swfitlint (minus to the 2 space indents) (GitHub - raywenderlich/swift-style-guide: The official Swift style guide for raywenderlich.com.). Just curious if there's a common setup people are using.

1 Like

I do not know why people keep getting this impression. It is the standard tool and will eventually be included in the Swift toolchain itself.

1 Like

Are you using it? With the stock settings/configuration?

I haven't heard any specific plans on this, do you have a link?

It’s been 2 and a half years since it was pitched. I think it’s time to accept that it isn’t going to happen.

It’s a shame; swift-format is really good. Not perfect, but really good. I’ve gotten so used to it, it’s like a little game now every time I commit something, to see if I can write code in a way that swift-format will accept as-is.

1 Like

Separate from swift-format, and generally superior, is swiftformat. It's pretty complete, has a responsive dev, and can be customized. In combination with SwiftLint, all your formatting and linting needs should be taken care of.



More or less. (And many of those adjustments are no longer necessary due to fixes since that release.)

This is not the vibe I get from either its primary developers or its other occasional contributors. @allevato, anything to say here?

I use SwiftLint for formatting and linting. It's mature, has a lot of linting rules, is fairly simple to configure, seems to be actively developed. I don't think there's a standard config file that's widely used. You could start with that rayW config file and comment out the rules you don't like. I have different projects with different teams where the coding style differs between the teams so some rules that are good for one project are no good for the other project. As far as formatting I like most of the basic rules, but given basic formatting the linting is more valuable to me.

Honestly I haven't tried the other options.

It's frustrating to me that we're on version 5.5 for Swift, mini-erlang/elixir was just subsumed into the language, and there's still no even semi-official "coding guidelines". Kotlin has a "standardized" code conventions (which they change from time to time of course).

Thanks for the advice though. It's what I'll probably end up doing.

We... tried? (SE-0250)

1 Like

I stewed on this for a few days. After re(reading) NSHipsters comments from way back on swiftlint, swift-format, and swiftformat, I ruled out swiftlint (I want whitespace managed more than it says it is). I was leaning towards swift-format, if nothing else because it's closer to the inner circles apparently. Then I noticed this:

~// brew info swift-format
install: 233 (30 days), 724 (90 days), 2,169 (365 days)
install-on-request: 231 (30 days), 721 (90 days), 2,167 (365 days)


~// brew info swiftformat
install: 5,263 (30 days), 13,469 (90 days), 52,556 (365 days)
install-on-request: 5,257 (30 days), 13,451 (90 days), 52,445 (365 days)

So for now, I'll be a drone and join the masses with swiftformat I think

1 Like

I do not know who created the Homebrew package, but I severely doubt it has official support. (It may not even be the same thing.) I suspect it would be quite brittle because swift‐format relies on interacting with the toolchain that built it. I recommend following the instructions in the read‐me instead.

I can't personally speak to what gets included in the Swift toolchains (nor do I have real any influence there), but I would still very much like swift-format to become the official formatting solution for Swift—it's just not something I've pushed as hard on recently, given other work that's higher impact/priority (both on my own plate, and for the Swift team). But as an example, there's an outstanding PR to integrate swift-format into sourcekit-lsp (currently blocked on supporting swift-format on swift-ci) which is already included in toolchains, so I think it's too soon to say "it isn't going to happen"; it may just take a bit more time.

FWIW, swift-format is still very much active even if it doesn't see day-to-day commits. It's the formatting and linting tool that supports every Swift developer at Google, and since its use is required for code to be checked in, any bugs or missing features that would result in broken or egregiously formatted code must be quickly addressed. (Though this will typically prioritize our own configuration matrix over others, which are less thoroughly tested...)

That's correct. I'm happy that folks in the community are contributing a Homebrew formula for swift-format if it makes it easier for people to install, but we don't support or contribute to it.


I want to say up front that all my tiny pull requests for swift-format reviewed by @allevato were quick and easy and nice. I believe you when you say that there are other, higher priority things to focus on, but...

As the author of that sourcekit-lsp PR I wouldn't use it as an example of any kind of progress. I wrote it one and a half years ago, and most of that time was spent waiting with zero progress towards merging it. I'm also a total outsider, not associated with Apple or swift-format so if it says anything, it says that Apple is very apathetic and indifferent about having swift-format integrated.


That's great to hear. As I'm trying to apply the Google's Swift Style Guide, I guess using swift-format is therefore the natural fit for that task. Unfortunately, I do not see a config file in your styleguide repository; would you mind sharing the config you are using at Google for swift-format?

There isn't one, because the default configuration currently implements the formatting rules in that guide (modulo some changes to our internal version of the guide that I need to find time to push out to the public version). So running swift-format without specifying a configuration will give you effectively the style described there.

There's no long-term guarantee that the default configuration will continue to use that style, but if the default changes then we'll encode the current style into a configuration file so that folks can continue to use it (or offer multiple built-in "named" configurations like clang-format does, maybe).