Lickability Swift Best Practices Guide
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. This style guide is intended to be a living repository that will be updated as the Swift language and our experience evolves. You can click through the links below to read individual sections, or you can read the full document here.
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 it our approach to writing software interesting-and if there are aspects that you'd love to chat about, let us know!
Architecture Info
Architecture Development Diagram
- M - Model
- V - View
- C - Controller
- VM - View Model
SwiftUI
Related Resources
Organizational Info
Technical Info
- Custom Operators
- Default Parameters
- Localization
- Naming
- Interface Builder
- Object Communication
- Optionals
- Protocols
- Testing
- Zero Usage
Style
We use SwiftLint for code linting. We avoid making style comments on pull requests wherever possible, instead allowing the linter to catch them while developing. The fully documented .yml file we use is located here.
SwiftUI / Combine
The majority of this document was written prior to the introduction of SwiftUI and Combine. As we become more familiar with these technologies and use them in our own projects, we expect them to reshape the best practices as it exists today.