Engineering

Our Swift Best Practices

Lickability’s guide to writing better Swift

Code is written for humans. I’m not the first to say that, and won’t be the last. What you write will eventually be compiled away into something unintelligible, so how you choose to write code isn’t for the computer’s benefit. It’s for yourself, both now and later. It’s for any people working on a team with you. And it’s for anyone that stumbles upon your code after you’re gone.

In order to understand our code better, Lickability employs consistent practices — and to do that, we have a defined structure and style for the way we write code. Today, we’re sharing our best practices guide with you. This guide contains our preferred way of writing code, both in terms of architecture and the way style is enforced (through SwiftLint). It is intended to be a living repository that will be updated as the Swift language and our experience evolves.

If you want to use this, great! If you want to fork it and make changes, go ahead. We won’t be accepting issues or pull requests at this time, but we hope that you’ll find our approach to writing software interesting—and if there are aspects that you’d love to chat about, let us know!