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 Development Diagram

• M - Model
• V - View
• C - Controller
• VM - View Model

• General Best Practices
• View Store

• Common Controller Types
• Access Control

• Assets
• Documentation and Comments
• Extensions
• Imports
• Organization Within a File
• Project Groups

• Custom Operators
• Default Parameters
• Localization
• Naming
• Interface Builder
• Object Communication
• Optionals
• Protocols
• Testing
• Zero Usage

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.

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.