Recently, we’ve developed our first Swift app, with a few folks involved, and most of them new to Swift. The problem I want to describe emerged pretty quickly and there was only one way to deal with it - outlining our own Swift style guide.
Recently, we’ve developed our first Swift app, with a few folks involved, and most of them new to Swift. The problem I want to describe emerged pretty quickly and there was only one way to deal with it - outlining our own Swift style guide so that we don’t get lost in our own work.
Diving into Swift
As Swift newbies, everyone was discovering some new language feature every day, every hour and in almost every commit. Each of us understood Swift a bit differently, which resulted in using newly learned features in different ways as well. If you like the word consistency, now think incongruity - and that’s a better term to depict what was happening in our code. However, not all was lost and we didn’t make mistakes that can’t be fixed. As a result, I said “Basta!” and created the Swift Style Guide.
First of all, our guide isn’t a unicorn, and we realise there are some other great resources, too. On the other hand, I believe we took the very essence of the ones we based on. We used the sources by:
The purpose of our guide is to improve code consistency and readability in the first place. I didn’t mean to create any sort of manifesto, but to make suggestions for other developers using Swift. It’s easier to follow tips than commandments because it helps to resolve contentious situations. Commandments mostly mean limitations, and we want to be flexible about code, not limited.
It took us some time to establish the ground rules. Some are taken right from other guides - because we think they’re great! - but most of them are a result of our work with Swift and code review discussions. This is how we found a proverbial golden mean.
Problems with Swift
Some of the problems may sound trivial or not worth mentioning, but they have an influence on code quality, which means they actually are important - at least to us.
These are some problems we addressed in the style guide:
the value of semantics over reference semantics.
I encourage you to check the entire guide, it’s meaty and I hope you can learn a lot from it!
Swift Style Guide is a part of Netguru’s open source activity and, as always, you’re welcome to comment, contribute and so on. You know what to do! :)
PS: My favorite part is the section Forbidden. Yes, we still didn’t break our own rule - not to tell what to do, we just tell you here what not to do.