Following this style guide should:
- Make it easier to read and begin understanding unfamiliar code.
- Make code easier to maintain.
- Reduce simple programmer errors.
- Keep discussions on diffs focused on the code's logic rather than its style.
Note that brevity is not a primary goal. Code should be made more concise only if other good code qualities (such as readability, simplicity, and clarity) remain equal or are improved.
- This guide is in addition to the official Swift API Design Guidelines. These rules should not contradict that document.
- These rules should not fight Xcode's ^ + I indentation behavior.
- 1.1 Use 4 spaces for tabs.
- 1.2 Avoid uncomfortably long lines with a hard maximum of 160 characters per line (Xcode->Preferences->Text Editing->Page guide at column: 160 is helpful for this)
- 1.3 Ensure that there is a newline at the end of every file.
- 1.4 Ensure that there is no trailing whitespace anywhere (Xcode->Preferences->Text Editing->Automatically trim trailing whitespace + Including whitespace-only lines).
- 1.5 Do not place opening braces on new lines - we use the 1TBS style.
class SomeClass {
func someMethod() {
if x == y {
/* ... */
} else if x == z {
/* ... */
} else {
/* ... */
}
}
/* ... */
}- 1.6 When writing a type for a property, constant, variable, a key for a dictionary, a function argument, a protocol conformance, or a superclass, don't add a space before the colon.
// specifying type
let pirateViewController: PirateViewController
// dictionary syntax (note that we left-align as opposed to aligning colons)
let ninjaDictionary: [String: AnyObject] = [
"fightLikeDairyFarmer": false,
"disgusting": true
]
// declaring a function
func myFunction<T, U: SomeProtocol>(firstArgument: U, secondArgument: T) where T.RelatedType == U {
/* ... */
}
// calling a function
someFunction(someArgument: "Kitten")
// superclasses
class PirateViewController: UIViewController {
/* ... */
}
// protocols
extension PirateViewController: UITableViewDataSource {
/* ... */
}- 1.7 In general, there should be a space following a comma.
let myArray = [1, 2, 3, 4, 5]- 1.8 There should be a space before and after a binary operator such as
+,==, or->. There should also not be a space after a(and before a).
let myValue = 20 + (30 / 2) * 3
if 1 + 1 == 3 {
fatalError("The universe is broken.")
}
func pancake(with syrup: Syrup) -> Pancake {
/* ... */
}- 1.9 We follow Xcode's recommended indentation style (i.e. your code should not change if CTRL-I is pressed). When declaring a function that spans multiple lines, prefer using that syntax to which Xcode, as of version 7.3, defaults.
// Xcode indentation for a function declaration that spans multiple lines
func myFunctionWithManyParameters(parameterOne: String,
parameterTwo: String,
parameterThree: String) {
// Xcode indents to here for this kind of statement
print("\(parameterOne) \(parameterTwo) \(parameterThree)")
}
// Xcode indentation for a multi-line `if` statement
if myFirstValue > (mySecondValue + myThirdValue)
&& myFourthValue == .someEnumValue {
// Xcode indents to here for this kind of statement
print("Hello, World!")
}- 1.10 When calling a function that has many parameters, put each argument on a separate line with a single extra indentation.
someFunctionWithManyArguments(
firstArgument: "Hello, I am a string",
secondArgument: resultFromSomeFunction(),
thirdArgument: someOtherLocalProperty)- 1.11 When dealing with an implicit array or dictionary large enough to warrant splitting it into multiple lines, treat the
[and]as if they were braces in a method,ifstatement, etc. Closures in a method should be treated similarly.
someFunctionWithABunchOfArguments(
someStringArgument: "hello I am a string",
someArrayArgument: [
"dadada daaaa daaaa dadada daaaa daaaa dadada daaaa daaaa",
"string one is crazy - what is it thinking?"
],
someDictionaryArgument: [
"dictionary key 1": "some value 1, but also some more text here",
"dictionary key 2": "some value 2"
],
someClosure: { parameter1 in
print(parameter1)
})- 1.12 Prefer using local constants or other mitigation techniques to avoid multi-line predicates where possible.
// PREFERRED
let firstCondition = x == firstReallyReallyLongPredicateFunction()
let secondCondition = y == secondReallyReallyLongPredicateFunction()
let thirdCondition = z == thirdReallyReallyLongPredicateFunction()
if firstCondition && secondCondition && thirdCondition {
// do something
}// NOT PREFERRED
if x == firstReallyReallyLongPredicateFunction()
&& y == secondReallyReallyLongPredicateFunction()
&& z == thirdReallyReallyLongPredicateFunction() {
// do something
}-
2.1 There is no need for Objective-C style prefixing in Swift (e.g. use just
GuybrushThreepwoodinstead ofLIGuybrushThreepwood). -
2.2 Use
PascalCasefor type names (e.g.struct,enum,class,typedef,associatedtype, etc.). -
2.3 Use
camelCase(initial lowercase letter) for function, method, property, constant, variable, argument names, enum cases, etc. -
2.4 All constants that are instance-independent should be
static. All suchstaticconstants should be placed in a marked section of theirclass,struct, orenum. For classes with many constants, you should group constants that have similar or the same prefixes, suffixes and/or use cases.
// PREFERRED
class MyClassName {
// MARK: - Constants
static let buttonPadding: CGFloat = 20.0
static let indianaPi = 3
static let shared = MyClassName()
}// NOT PREFERRED
class MyClassName {
// Don't use `k`-prefix
static let kButtonPadding: CGFloat = 20.0
// Don't namespace constants
enum Constant {
static let indianaPi = 3
}
}- 2.5 For generics and associated types, use a
PascalCaseword that describes the generic. If this word clashes with a protocol that it conforms to or a superclass that it subclasses, you can append aTypesuffix to the associated type or generic name.
class SomeClass<Model> { /* ... */ }
protocol Modelable {
associatedtype Model
}
protocol Sequence {
associatedtype IteratorType: Iterator
}- 2.6 Names should be descriptive and unambiguous.
// PREFERRED
class RoundAnimatingButton: UIButton { /* ... */ }// NOT PREFERRED
class CustomButton: UIButton { /* ... */ }- 2.7 Do not abbreviate, use shortened names, or single letter names.
// PREFERRED
class RoundAnimatingButton: UIButton {
let animationDuration: NSTimeInterval
func startAnimating() {
let firstSubview = subviews.first
}
}// NOT PREFERRED
class RoundAnimating: UIButton {
let aniDur: NSTimeInterval
func srtAnmating() {
let v = subviews.first
}
}- 2.8 Include type information in constant or variable names when it is not obvious otherwise.
// PREFERRED
class ConnectionTableViewCell: UITableViewCell {
let personImageView: UIImageView
let animationDuration: TimeInterval
// it is ok not to include string in the ivar name here because it's obvious
// that it's a string from the property name
let firstName: String
// though not preferred, it is OK to use `Controller` instead of `ViewController`
let popupController: UIViewController
let popupViewController: UIViewController
// when working with a subclass of `UIViewController` such as a table view
// controller, collection view controller, split view controller, etc.,
// fully indicate the type in the name.
let popupTableViewController: UITableViewController
// when working with outlets, make sure to specify the outlet type in the
// property name.
@IBOutlet weak var submitButton: UIButton!
@IBOutlet weak var emailTextField: UITextField!
@IBOutlet weak var nameLabel: UILabel!
}// NOT PREFERRED
class ConnectionTableViewCell: UITableViewCell {
// this isn't a `UIImage`, so shouldn't be called image
// use personImageView instead
let personImage: UIImageView
// this isn't a `String`, so it should be `textLabel`
let text: UILabel
// `animation` is not clearly a time interval
// use `animationDuration` or `animationTimeInterval` instead
let animation: TimeInterval
// this is not obviously a `String`
// use `transitionText` or `transitionString` instead
let transition: String
// this is a view controller - not a view
let popupView: UIViewController
// as mentioned previously, we don't want to use abbreviations, so don't use
// `VC` instead of `ViewController`
let popupVC: UIViewController
// even though this is still technically a `UIViewController`, this property
// should indicate that we are working with a *Table* View Controller
let popupViewController: UITableViewController
// for the sake of consistency, we should put the type name at the end of the
// property name and not at the start
@IBOutlet weak var btnSubmit: UIButton!
@IBOutlet weak var buttonSubmit: UIButton!
// we should always have a type in the property name when dealing with outlets
// for example, here, we should have `firstNameLabel` instead
@IBOutlet weak var firstName: UILabel!
}-
2.9 When naming function arguments, make sure that the function can be read easily to understand the purpose of each argument.
-
2.10 As per Apple's API Design Guidelines, a
protocolshould be named as nouns if they describe what something is doing (e.g.Collection) and using the suffixesable,ible, oringif it describes a capability (e.g.Equatable,ProgressReporting). If neither of those options makes sense for your use case, you can add aProtocolsuffix to the protocol's name as well. Some exampleprotocols are below.
// here, the name is a noun that describes what the protocol does
protocol TableViewSectionProvider {
func rowHeight(at row: Int) -> CGFloat
var numberOfRows: Int { get }
/* ... */
}
// here, the protocol is a capability, and we name it appropriately
protocol Loggable {
func logCurrentState()
/* ... */
}
// suppose we have an `InputTextView` class, but we also want a protocol
// to generalize some of the functionality - it might be appropriate to
// use the `Protocol` suffix here
protocol InputTextViewProtocol {
func sendTrackingEvent()
func inputText() -> String
/* ... */
}-
3.1.1 Prefer
lettovarwhenever possible. -
3.1.2 Prefer the composition of
map,filter,reduce, etc. over iterating when transforming from one collection to another. Make sure to avoid using closures that have side effects when using these methods.
// PREFERRED
let stringOfInts = [1, 2, 3].flatMap { String($0) }
// ["1", "2", "3"]// NOT PREFERRED
var stringOfInts: [String] = []
for integer in [1, 2, 3] {
stringOfInts.append(String(integer))
}// PREFERRED
let evenNumbers = [4, 8, 15, 16, 23, 42].filter { $0 % 2 == 0 }
// [4, 8, 16, 42]// NOT PREFERRED
var evenNumbers: [Int] = []
for integer in [4, 8, 15, 16, 23, 42] {
if integer % 2 == 0 {
evenNumbers.append(integer)
}
}-
3.1.3 Prefer not declaring types for constants or variables if they can be inferred anyway.
-
3.1.4 If a function returns multiple values, prefer returning a tuple to using
inoutarguments (it’s best to use labeled tuples for clarity on what you’re returning if it is not otherwise obvious). If you use a certain tuple more than once, consider using atypealias. If you’re returning 3 or more items in a tuple, consider using astructorclassinstead.
func pirateName() -> (firstName: String, lastName: String) {
return ("Guybrush", "Threepwood")
}
let name = pirateName()
let firstName = name.firstName
let lastName = name.lastName-
3.1.5 Be wary of retain cycles when creating delegates/protocols for your classes; typically, these properties should be declared
weak. -
3.1.6 Be careful when calling
selfdirectly from an escaping closure as this can cause a retain cycle - use a capture list when this might be the case:
myFunctionWithEscapingClosure() { [weak self] (error) -> Void in
// you can do this
self?.doSomething()
// or you can do this
guard let strongSelf = self else {
return
}
strongSelf.doSomething()
}-
3.1.7 Don't use labeled breaks.
-
3.1.8 Don't place parentheses around control flow predicates.
// PREFERRED
if x == y {
/* ... */
}// NOT PREFERRED
if (x == y) {
/* ... */
}- 3.1.9 Avoid writing out an
enumtype where possible - use shorthand.
// PREFERRED
imageView.setImageWithURL(url, type: .person)// NOT PREFERRED
imageView.setImageWithURL(url, type: AsyncImageView.Type.person)-
3.1.10 Prefer not writing
self.unless it is required. -
3.1.11 When writing methods, keep in mind whether the method is intended to be overridden or not. If not, mark it as
final, though keep in mind that this will prevent the method from being overwritten for testing purposes. In general,finalmethods result in improved compilation times, so it is good to use this when applicable. Be particularly careful, however, when applying thefinalkeyword in a library since it is non-trivial to change something to be non-finalin a library as opposed to have changing something to be non-finalin your local project. -
3.1.12 When using a statement such as
else,catch, etc. that follows a block, put this keyword on the same line as the block. Again, we are following the 1TBS style here. Exampleif/elseanddo/catchcode is below.
if someBoolean {
// do something
} else {
// do something else
}
do {
let fileContents = try readFile("filename.txt")
} catch {
print(error)
}-
3.1.13 Prefer
statictoclasswhen declaring a function or property that is associated with a class as opposed to an instance of that class. Only useclassif you specifically need the functionality of overriding that function or property in a subclass, though consider using aprotocolto achieve this instead. -
3.1.14 If you have a function that takes no arguments, has no side effects, and returns some object or value, prefer using a computed property instead.
- 3.2.1 Write the access modifier keyword first if it is needed.
// PREFERRED
private static let myPrivateNumber: Int// NOT PREFERRED
static private let myPrivateNumber: Int- 3.2.2 The access modifier keyword should not be on a line by itself - keep it inline with what it is describing.
// PREFERRED
open class Pirate {
/* ... */
}// NOT PREFERRED
open
class Pirate {
/* ... */
}-
3.2.3 In general, do not write the
internalaccess modifier keyword since it is the default. -
3.2.4 If a property needs to be accessed by unit tests, you will have to make it
internalto use@testable import ModuleName. If a property should be private, but you declare it to beinternalfor the purposes of unit testing, make sure you add an appropriate bit of documentation commenting that explains this. You can make use of the- warning:markup syntax for clarity as shown below. !Important: creation of such properties is allowed only in extreme cases. Use public interface of instance/type for testing!
/**
This property defines the pirate's name.
- warning: Not `private` for `@testable`.
*/
let pirateName = "LeChuck"-
3.2.5 Prefer
privatetofileprivatewhere possible. -
3.2.6 When choosing between
publicandopen, preferopenif you intend for something to be subclassable outside of a given module andpublicotherwise. Note that anythinginternaland above can be subclassed in tests by using@testable import, so this shouldn't be a reason to useopen. In general, lean towards being a bit more liberal with usingopenwhen it comes to libraries, but a bit more conservative when it comes to modules in a codebase such as an app where it is easy to change things in multiple modules simultaneously.
Prefer creating named functions to custom operators.
You can override existing operators to support new types (especially ==). However, your new definitions must preserve the semantics of the operator. For example, == must always test equality and return a boolean.
-
3.4.1 When using a switch statement that has a finite set of possibilities (
enum), do NOT include adefaultcase. Instead, place unused cases at the bottom and use thebreakkeyword to prevent execution. -
3.4.2 Since
switchcases in Swift break by default, do not include thebreakkeyword if it is not needed. -
3.4.3 The
casestatements should line up with theswitchstatement itself as per default Swift standards. -
3.4.4 When defining a case that has an associated value, make sure that this value is appropriately labeled as opposed to just types (e.g.
case hunger(hungerLevel: Int)instead ofcase hunger(Int)).
enum Problem {
case attitude
case hair
case hunger(hungerLevel: Int)
}
func handleProblem(problem: Problem) {
switch problem {
case .attitude:
print("At least I don't have a hair problem.")
case .hair:
print("Your barber didn't know when to stop.")
case .hunger(let hungerLevel):
print("The hunger level is \(hungerLevel).")
}
}-
3.4.5 Prefer lists of possibilities (e.g.
case 1, 2, 3:) to using thefallthroughkeyword where possible). -
3.4.6 If you have a default case that shouldn't be reached, preferably throw an error (or handle it some other similar way such as asserting).
func handleDigit(_ digit: Int) throws {
switch digit {
case 0, 1, 2, 3, 4, 5, 6, 7, 8, 9:
print("Yes, \(digit) is a digit!")
default:
throw Error(message: "The given number was not a digit.")
}
}-
3.5.1 You should use implicitly unwrapped optionals with
@IBOutlets and in unit tests only. In every other case, it is better to use a non-optional or regular optional property. Yes, there are cases in which you can probably "guarantee" that the property will never benilwhen used, but it is better to be safe and consistent. Similarly, don't use force unwraps. -
3.5.2 Don't use
as!ortry!. -
3.5.3 If you don't plan on actually using the value stored in an optional, but need to determine whether or not this value is
nil, explicitly check this value againstnilas opposed to usingif letsyntax.
// PREFERERED
if someOptional != nil {
// do something
}// NOT PREFERRED
if let _ = someOptional {
// do something
}- 3.5.4 Don't use
unowned. You can think ofunownedas somewhat of an equivalent of aweakproperty that is implicitly unwrapped (thoughunownedhas slight performance improvements on account of completely ignoring reference counting). Since we don't ever want to have implicit unwraps, we similarly don't wantunownedproperties.
// PREFERRED
weak var parentViewController: UIViewController?// NOT PREFERRED
weak var parentViewController: UIViewController!
unowned var parentViewController: UIViewController- 3.5.5 When unwrapping optionals, use the same name for the unwrapped constant or variable where appropriate.
guard let myValue = myValue else {
return
}When implementing protocols, there are two ways of organizing your code:
- Using
// MARK:comments to separate your protocol implementation from the rest of your code - Using an extension outside your
class/structimplementation code, but in the same source file
Keep in mind that when using an extension, however, the methods in the extension can't be overridden by a subclass, which can make testing difficult. If this is a common use case, it might be better to stick with method #1 for consistency. Otherwise, method #2 allows for cleaner separation of concerns.
Even when using method #2, add // MARK: statements anyway for easier readability in Xcode's method/property/class/etc. list UI.
Since Xcode can't render class declaration in quick help during protocol conformance announced in extensions properly, it's better to put it after class declaration.
// PREFERRED
class MyViewController: UIViewController, UITableViewDataSource, UIScrollViewDelegate {
// class stuff here
}
// MARK: - UITableViewDataSource
extension MyViewController {
// table view data source methods
}
// MARK: - UIScrollViewDelegate
extension MyViewController {
// scroll view delegate methods
}// NOT PREFERRED
class MyViewController: UIViewController, UITableViewDataSource, UIScrollViewDelegate {
// all methods
}- 3.7.1 If making a read-only, computed property, provide the getter without the
get {}around it.
var computedProperty: String {
if someBool {
return "I'm a mighty pirate!"
}
return "I'm selling these fine leather jackets."
}- 3.7.2 When using
get {},set {},willSet, anddidSet, indent these blocks. - 3.7.3 Though you can create a custom name for the new or old value for
willSet/didSetandset, use the standardnewValue/oldValueidentifiers that are provided by default.
var storedProperty: String = "I'm selling these fine leather jackets." {
willSet {
print("will set to \(newValue)")
}
didSet {
print("did set from \(oldValue) to \(storedProperty)")
}
}
var computedProperty: String {
get {
if someBool {
return "I'm a mighty pirate!"
}
return storedProperty
}
set {
storedProperty = newValue
}
}- 3.7.4 Avoid using singletons
- 3.8.1 If the types of the parameters are obvious, it is OK to omit the type name, but being explicit is also OK. Sometimes readability is enhanced by adding clarifying detail and sometimes by taking repetitive parts away - use your best judgment and be consistent.
// omitting the type
doSomethingWithClosure() { response in
print(response)
}
// explicit type
doSomethingWithClosure() { response: NSURLResponse in
print(response)
}
// using shorthand in a map statement
[1, 2, 3].flatMap { String($0) }- 3.8.2 If specifying a closure as a type, you don’t need to wrap it in parentheses unless it is required (e.g. if the type is optional or the closure is within another closure). Always wrap the arguments in the closure in a set of parentheses - use
()to indicate no arguments and useVoidto indicate that nothing is returned.
let completionBlock: (Bool) -> Void = { (success) in
print("Success? \(success)")
}
let completionBlock: () -> Void = {
print("Completed!")
}
let completionBlock: (() -> Void)? = nil-
3.8.3 Keep parameter names on same line as the opening brace for closures when possible without too much horizontal overflow (i.e. ensure lines are less than 160 characters).
-
3.8.4 Use trailing closure syntax unless the meaning of the closure is not obvious without the parameter name (an example of this could be if a method has parameters for success and failure closures).
// trailing closure
doSomething(1.0) { (parameter1) in
print("Parameter 1 is \(parameter1)")
}
// no trailing closure
doSomething(1.0, success: { (parameter1) in
print("Success with \(parameter1)")
}, failure: { (parameter1) in
print("Failure with \(parameter1)")
})-
3.9.1 In general, avoid accessing an array directly with subscripts. When possible, use accessors such as
.firstor.last, which are optional and won’t crash. Prefer using afor item in itemssyntax when possible as opposed to something likefor i in 0 ..< items.count. If you need to access an array subscript directly, make sure to do proper bounds checking. You can usefor (index, value) in items.enumerated()to get both the index and the value. -
3.9.2 Never use the
+=or+operator to append/concatenate to arrays. Instead, use.append()or.append(contentsOf:)as these are far more performant (at least with respect to compilation) in Swift's current state.
Suppose a function myFunction is supposed to return a String, however, at some point it can run into an error. A common approach is to have this function return an optional String? where we return nil if something went wrong.
Example:
// NOT PREFERRED
func readFile(named filename: String) -> String? {
guard let file = openFile(named: filename) else {
return nil
}
let fileContents = file.read()
file.close()
return fileContents
}
func printSomeFile() {
let filename = "somefile.txt"
guard let fileContents = readFile(named: filename) else {
print("Unable to open file \(filename).")
return
}
print(fileContents)
}Instead, we should be using Swift's try/catch behavior when it is appropriate to know the reason for the failure.
You can use a struct such as the following:
struct Error: Swift.Error {
public let file: StaticString
public let function: StaticString
public let line: UInt
public let message: String
public init(message: String, file: StaticString = #file, function: StaticString = #function, line: UInt = #line) {
self.file = file
self.function = function
self.line = line
self.message = message
}
}Example usage:
// REFERRED
func readFile(named filename: String) throws -> String {
guard let file = openFile(named: filename) else {
throw Error(message: "Unable to open file named \(filename).")
}
let fileContents = file.read()
file.close()
return fileContents
}
func printSomeFile() {
do {
let fileContents = try readFile(named: filename)
print(fileContents)
} catch {
print(error)
}
}There are some exceptions in which it does make sense to use an optional as opposed to error handling. When the result should semantically potentially be nil as opposed to something going wrong while retrieving the result, it makes sense to return an optional instead of using error handling.
In general, if a method can "fail", and the reason for the failure is not immediately obvious if using an optional return type, it probably makes sense for the method to throw an error.
- 3.11.1 In general, we prefer to use an "early return" strategy where applicable as opposed to nesting code in
ifstatements. Usingguardstatements for this use-case is often helpful and can improve the readability of the code.
// PREFERRED
func eatDoughnut(at index: Int) {
guard index >= 0 && index < doughnuts.count else {
// return early because the index is out of bounds
return
}
let doughnut = doughnuts[index]
eat(doughnut)
}// NOT PREFERRED
func eatDoughnut(at index: Int) {
if index >= 0 && index < doughnuts.count {
let doughnut = doughnuts[index]
eat(doughnut)
}
}- 3.11.2 When unwrapping optionals, prefer
guardstatements as opposed toifstatements to decrease the amount of nested indentation in your code.
// PREFERRED
guard let monkeyIsland = monkeyIsland else {
return
}
bookVacation(on: monkeyIsland)
bragAboutVacation(at: monkeyIsland)// NOT PREFERRED
if let monkeyIsland = monkeyIsland {
bookVacation(on: monkeyIsland)
bragAboutVacation(at: monkeyIsland)
}
// EVEN LESS PREFERRED
if monkeyIsland == nil {
return
}
bookVacation(on: monkeyIsland!)
bragAboutVacation(at: monkeyIsland!)- 3.11.3 When deciding between using an
ifstatement or aguardstatement when unwrapping optionals is not involved, the most important thing to keep in mind is the readability of the code. There are many possible cases here, such as depending on two different booleans, a complicated logical statement involving multiple comparisons, etc., so in general, use your best judgement to write code that is readable and consistent. If you are unsure whetherguardorifis more readable or they seem equally readable, prefer usingguard.
// an `if` statement is readable here
if operationFailed {
return
}
// a `guard` statement is readable here
guard isSuccessful else {
return
}
// double negative logic like this can get hard to read - i.e. don't do this
guard !operationFailed else {
return
}- 3.11.4 If choosing between two different states, it makes more sense to use an
ifstatement as opposed to aguardstatement.
// PREFERRED
if isFriendly {
print("Hello, nice to meet you!")
} else {
print("You have the manners of a beggar.")
}// NOT PREFERRED
guard isFriendly else {
print("You have the manners of a beggar.")
return
}
print("Hello, nice to meet you!")- 3.11.5 You should also use
guardonly if a failure should result in exiting the current context. Below is an example in which it makes more sense to use twoifstatements instead of using twoguards - we have two unrelated conditions that should not block one another.
if let monkeyIsland = monkeyIsland {
bookVacation(onIsland: monkeyIsland)
}
if let woodchuck = woodchuck, canChuckWood(woodchuck) {
woodchuck.chuckWood()
}- 3.11.6 Often, we can run into a situation in which we need to unwrap multiple optionals using
guardstatements. In general, combine unwraps into a singleguardstatement if handling the failure of each unwrap is identical (e.g. just areturn,break,continue,throw, or some other@noescape).
// combined because we just return
guard let thingOne = thingOne,
let thingTwo = thingTwo,
let thingThree = thingThree else {
return
}
// separate statements because we handle a specific error in each case
guard let thingOne = thingOne else {
throw Error(message: "Unwrapping thingOne failed.")
}
guard let thingTwo = thingTwo else {
throw Error(message: "Unwrapping thingTwo failed.")
}
guard let thingThree = thingThree else {
throw Error(message: "Unwrapping thingThree failed.")
}- 4.1.1 Always leave a space after
//. - 4.1.2 Always leave comments on their own line.