When I was at my last place many different developers over the years had worked in the code base. So there ended up being many different styles of how the code was wrote. This was distracting and confusing. We had a new batch of developers join the company and some had some had some very strong ideas of how they wanted there code to look. This became problematic as code reviews slowed down because there was more discussion about how the code looked then about how it actually worked. With no agreed up on team standard you didn’t know when putting up the review if it was what people would accept. Even though it was worded as suggestions, I always wanted the code to look better. So after we had a bunch of reviews slow down because of this we started talking about how we could format the code so that everyone would agree on it. We had all worked with source code formatters in the past and I was tasked with looking into what would work for Swift. And here is what I found.

Apple has it’s own Swift Format that is available via open source on GitHub. There has very little configuration options, which seems on purpose for a product from Apple. Next I found another SwiftFormat from Nick Lockwood. This tool had a lot more configuration options and an active community around. It looked like a good a candidate to try. Finally I found that SwiftLint had an format option. This really wasn’t what we were looking for.

After playing around with the two Swift Formats and putting up some demo pull requests in which I tried to format the code to a quasi agreed upon team standard. We agreed that the Nick Lockwood’s SwiftFormat was the best choice. Not perfect, but much better then the alternatives. We then went through all the rules available and picked the options we liked. Finally I put up a Pull Request that formatted the code base in the new format and applied and enforced the new rules.

Interestingly, originally we applied the formatting during one of the build steps. This only formatted the files you changed. But there is a bug that the formatter will fail if a file has a space in it. Yes, it’s 2020 and there still issues with file names with spaces. Maybe we should go back to the 8.3 format. Okay, rant over. So we changed the formatter to format all the source code. Xcode did not like this. It does really poorly with external sources changing file contents and pops up a dialog to revert or keep what’s in the editor. This became really annoying and we had to remove the formatter as a build step. Instead we put it in a pre-commit hook. This wasn’t perfect, but much better then trying to make people do it manually or in Xcode. Also another thing that was done is that the build script would format the source base and if there were any differences when it was done, the build would fail. This was a great fail safe for when developers forgot to format or hadn’t correctly setup there pre-commit hook.

So what did this net us? Well pull requests turned back to being more about the logic of the code. Conversations about the formatting were kept to a minimum as we had an agreed upon standard, not perfect, but nothing really is. This also made the code feel owned by the team as it was in the teams style. So pull-requests had a lot less back and forth and made us move quicker. Also we didn’t need a document describing our team’s source code format style, the code show cased the style.

I would strongly encourage any team to use SwiftFormat. The sooner the better because if there are big enough differences when the code is formatted the history of those changes will get all mangled. Thanks and have a great day.