├── README.md
└── swift-style-guide.md


/README.md:
--------------------------------------------------------------------------------
 1 | # Advanced Swift Notes
 2 | 
 3 | A collection of notes on the excellent book [Advanced Swift](https://www.objc.io/books/advanced-swift/) by Chris Eidhof and Airspeed Velocity.
 4 | 
 5 | [Swift Style Guide](swift-style-guide.md)
 6 | 
 7 | ###Array
 8 | 
 9 | `Array` is a value types but the items it contains _may_ not be. Assigning an `Array` to a new constant or variable creates a shallow copy unless the items held are also value types in which case it is a deep copy.
10 | 
11 | `SequenceType`'s `map`, `filter` and `reduce` remove the boiler plate code of a simliar operation allowing the unique transformation code to surface.
12 | 
13 | It is possible to use `sort` and `contains` in interesting ways. ie.
14 | 
15 | `people.contains { $0.age < 18 }`
16 | 
17 | Consider writing extensions for `SequenceType` when you find yourself writing collection lookup code.
18 | 
19 | Handy functions
20 | ```
21 | extension SequenceType {
22 |     func findElement (match: Generator.Element->Bool) -> Generator.Element? {
23 |         for element in self where match(element) {
24 |             return element
25 |         }
26 |         return nil
27 |     }
28 | }
29 | ```
30 | 
31 | Excerpt From: Chris Eidhof. “Advanced Swift.” iBooks. 
32 | 
33 | ###Dictionary
34 | 
35 | Handy functions
36 | ```
37 | extension Dictionary {
38 |     mutating func merge<S: SequenceType
39 |         where S.Generator.Element == (Key,Value)>(other: S) {
40 |         for (k, v) in other {
41 |             self[k] = v
42 |         }
43 |     }
44 | }
45 | ```
46 | 
47 | ###SequenceType (generally)
48 | ```
49 | extension SequenceType where Generator.Element: Hashable {
50 |     func unique() -> [Generator.Element] {
51 |         var seen: Set<Generator.Element> = []
52 |         return filter {
53 |             if seen.contains($0) {
54 |                 return false
55 |             } else {
56 |                 seen.insert($0)
57 |                 return true
58 |             }
59 |         }
60 |     }
61 | }
62 | ```


--------------------------------------------------------------------------------
/swift-style-guide.md:
--------------------------------------------------------------------------------
 1 | #Swift Style Guide
 2 | 
 3 | When writing this book, and when writing Swift code for our own projects, we try to stick to the following rules:
 4 | 
 5 | 1. Readability is most important. This is helped by brevity.
 6 | 
 7 | 1. Always add documentation comments to functions — especially generic ones.
 8 | 
 9 | 1. Types start with UpperCaseLetters. Functions and variables start with lowerCaseLetters.
10 | 
11 | 1. Use type inference. Explicit but obvious types get in the way of readability.
12 | 
13 | 1. Don’t use type inference in cases of ambiguity or when defining contracts (which is why, for example,funcs have an explicit return type).
14 | 
15 | 1. Default to structs unless you actually need a class-only feature or reference semantics.
16 | 
17 | 1. Mark classes as final unless you’ve explicitly designed them to be inheritable.
18 | 
19 | 1. Use the trailing closure syntax, except when that closure is immediately followed by another opening brace.
20 | 
21 | 1. Use guard to exit functions early.
22 | 
23 | 1. Eschew force-unwraps and implicitly unwrapped optionals. They are occasionally useful, but needing them constantly is usually a sign something else is wrong.
24 | 
25 | 1. Don’t repeat yourself. If you find you have written a very similar piece of code more than a couple of times, extract it into a function. Consider making that function a protocol extension.
26 | 
27 | 1. Favor map and reduce. But don’t force it: use a for loop when it makes sense. The purpose of higher-order functions is to make code more readable. An obfuscated use of reduce when a simple for loop would be clearer defeats this purpose.
28 | 
29 | 1. Favor immutability: default to let unless you know you need mutation. But use mutation when it makes the code clearer or more efficient. Wrap that mutation in a function to isolate unexpected side effects.
30 | 
31 | 1. Swift generics tend to lead to very long function signatures. Unfortunately, we have yet to settle on a good way of breaking up long function declarations into multiple lines. We’ll try to be consistent in how we do this in sample code.
32 | 
33 | 1. Much to the dismay of half of this book’s authorship, the “cuddled else” is official Swift style: } else {.


--------------------------------------------------------------------------------