Swift is a language whose goal is to be easy to write and read, perform well, and let the compiler do a lot of the work for you. These guidelines attempt to assist in achieving that goal.
If you have not already, read The Swift Programming Language (also available as a book!). That introduces concepts and patterns in a way that’s necessary before reading this guide.
If that book doesn’t appeal to you, to can also look at Apple’s Swift Language Guide, which is in a more traditional documentation format, including lexical structure.
Overall, embrace Swift. Swift-y patterns in
.swift files are preferred over patterns used in other languages. Following this simple rule helps the compiler create better assembly, avoids bugs, and makes the code more maintainable.
If you disagree with any of these or have something new to add, you are encouraged to create a pull request or issue using the links at the bottom.
These guidelines are relevant and accurate as of Swift 5.1
Primarily, if anything is not explicitly defined here, defer to the below list (prefer items higher on the list). If you still can’t find anything in this or those guides, then what you are trying to do is freeform; do it however you prefer.
With very few exceptions, if Xcode’s build-in code completion/formatting does it some way, that is the way we want it done. If the compiler issues a warning about it, address that warning. Don’t fight the IDE.
- The Swift.org API Design Guidelines
- HIGHLY ENCOURAGED! WWDC 2016 Session 403: Official | Unofficial YouTube mirror
- Google’s Swift Style Guide
- The style already present in the file you’re editing