├── .swiftlint.yml
├── LICENSE
├── README.md
└── images
    ├── cuddled.png
    ├── metova.png
    └── uncuddled.png


/.swiftlint.yml:
--------------------------------------------------------------------------------
 1 | # SwiftLint version 0.11.1
 2 | 
 3 | disabled_rules: # rule identifiers to exclude from running
 4 |   - valid_docs
 5 |   - line_length
 6 |   - todo
 7 |   - trailing_whitespace
 8 |   - nesting
 9 | opt_in_rules: # some rules are only opt-in
10 |   - empty_count
11 |   - force_unwrapping
12 | excluded: # paths to ignore during linting. Takes precedence over `included`.
13 |   - Pods
14 |   - Vendor
15 |   - build
16 | 
17 | 
18 | # configurable rules can be customized from this configuration file
19 | # binary rules can set their severity level
20 | force_cast: error
21 | force_try: error
22 | force_unwrapping: error
23 | 
24 | statement_position:
25 |    statement_mode: uncuddled_else
26 | 
27 | file_length:
28 |   warning: 900
29 | variable_name:
30 |   max_length:
31 |     warning: 55
32 |     error: 60
33 |   min_length:
34 |     error: 3
35 |   excluded:
36 |     - url
37 | type_name:
38 |   max_length:
39 |     warning: 55
40 |     error: 60
41 |   min_length:
42 |     error: 3
43 |   excluded:
44 |     - iPhone
45 |     - iPad
46 | type_body_length:
47 |    warning: 300
48 |    error: 900
49 | function_body_length:
50 |    warning: 50
51 |    error: 100
52 | function_parameter_count:
53 |    warning: 6
54 |    error: 8
55 | cyclomatic_complexity:
56 |    warning: 12
57 |    error: 20
58 | 
59 | # custom rules follow. (here be regex dragons)
60 | 
61 | custom_rules:
62 |    empty_line_after_super:
63 |       name: "Empty Line After Super"
64 |       regex: "(^ *super\.[ a-zA-Z0-9=?.\(\)\{\}:,><!]*\n *(?!(?:\}|return))\S+)"
65 |       message: "There should be an empty line after super"
66 |       severity: error
67 |    unnecessary_type:
68 |       name: "Unnecessary Type"
69 |       regex: "[ a-zA-Z0-9]*(?:let|var) [ a-zA-Z0-9]*: ([a-zA-Z0-9]*)[\? ]*= \1"
70 |       message: "Type Definition Not Needed"
71 |       severity: error
72 |    multiple_empty_lines:
73 |       name: "Multiple Empty Lines"
74 |       regex: "((?:\s*\n){3,})"
75 |       message: "There are too many line breaks"
76 |       severity: error
77 |    empty_line_after_guard:
78 |       name: "Empty Line After Guard"
79 |       regex: "(^ *guard[ a-zA-Z0-9=?.\(\),><!]*\{[ a-zA-Z0-9=?.\(\),><!]*\}\n *(?!(?:return|guard))\S+)"
80 |       message: "There should be an empty line after a guard"
81 |       severity: error
82 | 


--------------------------------------------------------------------------------
/LICENSE:
--------------------------------------------------------------------------------
  1 | CC0 1.0 Universal
  2 | 
  3 | Statement of Purpose
  4 | 
  5 | The laws of most jurisdictions throughout the world automatically confer
  6 | exclusive Copyright and Related Rights (defined below) upon the creator and
  7 | subsequent owner(s) (each and all, an "owner") of an original work of
  8 | authorship and/or a database (each, a "Work").
  9 | 
 10 | Certain owners wish to permanently relinquish those rights to a Work for the
 11 | purpose of contributing to a commons of creative, cultural and scientific
 12 | works ("Commons") that the public can reliably and without fear of later
 13 | claims of infringement build upon, modify, incorporate in other works, reuse
 14 | and redistribute as freely as possible in any form whatsoever and for any
 15 | purposes, including without limitation commercial purposes. These owners may
 16 | contribute to the Commons to promote the ideal of a free culture and the
 17 | further production of creative, cultural and scientific works, or to gain
 18 | reputation or greater distribution for their Work in part through the use and
 19 | efforts of others.
 20 | 
 21 | For these and/or other purposes and motivations, and without any expectation
 22 | of additional consideration or compensation, the person associating CC0 with a
 23 | Work (the "Affirmer"), to the extent that he or she is an owner of Copyright
 24 | and Related Rights in the Work, voluntarily elects to apply CC0 to the Work
 25 | and publicly distribute the Work under its terms, with knowledge of his or her
 26 | Copyright and Related Rights in the Work and the meaning and intended legal
 27 | effect of CC0 on those rights.
 28 | 
 29 | 1. Copyright and Related Rights. A Work made available under CC0 may be
 30 | protected by copyright and related or neighboring rights ("Copyright and
 31 | Related Rights"). Copyright and Related Rights include, but are not limited
 32 | to, the following:
 33 | 
 34 |   i. the right to reproduce, adapt, distribute, perform, display, communicate,
 35 |   and translate a Work;
 36 | 
 37 |   ii. moral rights retained by the original author(s) and/or performer(s);
 38 | 
 39 |   iii. publicity and privacy rights pertaining to a person's image or likeness
 40 |   depicted in a Work;
 41 | 
 42 |   iv. rights protecting against unfair competition in regards to a Work,
 43 |   subject to the limitations in paragraph 4(a), below;
 44 | 
 45 |   v. rights protecting the extraction, dissemination, use and reuse of data in
 46 |   a Work;
 47 | 
 48 |   vi. database rights (such as those arising under Directive 96/9/EC of the
 49 |   European Parliament and of the Council of 11 March 1996 on the legal
 50 |   protection of databases, and under any national implementation thereof,
 51 |   including any amended or successor version of such directive); and
 52 | 
 53 |   vii. other similar, equivalent or corresponding rights throughout the world
 54 |   based on applicable law or treaty, and any national implementations thereof.
 55 | 
 56 | 2. Waiver. To the greatest extent permitted by, but not in contravention of,
 57 | applicable law, Affirmer hereby overtly, fully, permanently, irrevocably and
 58 | unconditionally waives, abandons, and surrenders all of Affirmer's Copyright
 59 | and Related Rights and associated claims and causes of action, whether now
 60 | known or unknown (including existing as well as future claims and causes of
 61 | action), in the Work (i) in all territories worldwide, (ii) for the maximum
 62 | duration provided by applicable law or treaty (including future time
 63 | extensions), (iii) in any current or future medium and for any number of
 64 | copies, and (iv) for any purpose whatsoever, including without limitation
 65 | commercial, advertising or promotional purposes (the "Waiver"). Affirmer makes
 66 | the Waiver for the benefit of each member of the public at large and to the
 67 | detriment of Affirmer's heirs and successors, fully intending that such Waiver
 68 | shall not be subject to revocation, rescission, cancellation, termination, or
 69 | any other legal or equitable action to disrupt the quiet enjoyment of the Work
 70 | by the public as contemplated by Affirmer's express Statement of Purpose.
 71 | 
 72 | 3. Public License Fallback. Should any part of the Waiver for any reason be
 73 | judged legally invalid or ineffective under applicable law, then the Waiver
 74 | shall be preserved to the maximum extent permitted taking into account
 75 | Affirmer's express Statement of Purpose. In addition, to the extent the Waiver
 76 | is so judged Affirmer hereby grants to each affected person a royalty-free,
 77 | non transferable, non sublicensable, non exclusive, irrevocable and
 78 | unconditional license to exercise Affirmer's Copyright and Related Rights in
 79 | the Work (i) in all territories worldwide, (ii) for the maximum duration
 80 | provided by applicable law or treaty (including future time extensions), (iii)
 81 | in any current or future medium and for any number of copies, and (iv) for any
 82 | purpose whatsoever, including without limitation commercial, advertising or
 83 | promotional purposes (the "License"). The License shall be deemed effective as
 84 | of the date CC0 was applied by Affirmer to the Work. Should any part of the
 85 | License for any reason be judged legally invalid or ineffective under
 86 | applicable law, such partial invalidity or ineffectiveness shall not
 87 | invalidate the remainder of the License, and in such case Affirmer hereby
 88 | affirms that he or she will not (i) exercise any of his or her remaining
 89 | Copyright and Related Rights in the Work or (ii) assert any associated claims
 90 | and causes of action with respect to the Work, in either case contrary to
 91 | Affirmer's express Statement of Purpose.
 92 | 
 93 | 4. Limitations and Disclaimers.
 94 | 
 95 |   a. No trademark or patent rights held by Affirmer are waived, abandoned,
 96 |   surrendered, licensed or otherwise affected by this document.
 97 | 
 98 |   b. Affirmer offers the Work as-is and makes no representations or warranties
 99 |   of any kind concerning the Work, express, implied, statutory or otherwise,
100 |   including without limitation warranties of title, merchantability, fitness
101 |   for a particular purpose, non infringement, or the absence of latent or
102 |   other defects, accuracy, or the present or absence of errors, whether or not
103 |   discoverable, all to the greatest extent permissible under applicable law.
104 | 
105 |   c. Affirmer disclaims responsibility for clearing rights of other persons
106 |   that may apply to the Work or any use thereof, including without limitation
107 |   any person's Copyright and Related Rights in the Work. Further, Affirmer
108 |   disclaims responsibility for obtaining any necessary consents, permissions
109 |   or other rights required for any use of the Work.
110 | 
111 |   d. Affirmer understands and acknowledges that Creative Commons is not a
112 |   party to this document and has no duty or obligation with respect to this
113 |   CC0 or use of the Work.
114 | 
115 | For more information, please see
116 | <http://creativecommons.org/publicdomain/zero/1.0/>
117 | 


--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
  1 | ![Metova Swift Style Guide](images/metova.png)
  2 | 
  3 | # [DEPRECATED] (Dec. 2022)
  4 | Note that this repo is being archived due to lack of updates. There are many great alternatives today, including [Apple's](https://www.swift.org/documentation/api-design-guidelines/) and [Google's](https://google.github.io/swift/) design/styling guidelines.
  5 | 
  6 | # Metova's Swift Style Guide
  7 | 
  8 | This style guide is written primarily with the development of iOS and OS X applications using the Xcode IDE in mind.  As such, many of the guidelines found within are based around consistency with Apple's frameworks & Xcode's default preferences.  If you are developing with Swift using different frameworks, or a different IDE, you may find sections of this style guide to be less applicable.
  9 | 
 10 | ## Table of Contents
 11 | 
 12 | * [General](#general)
 13 |   * [Whitespace](#whitespace)
 14 |   * [Braces](#braces)
 15 |   * [Control Flow](#control-flow)
 16 |   * [Loops](#loops)
 17 | * [Classes and Structures](#classes-and-structures)
 18 |   * [Avoid Explicit Use of Self](#avoid-explicit-use-of-self-except-where-required)
 19 | * [Closures](#closures)
 20 | * [Types](#types)
 21 |   * [Constants](#constants)
 22 |   * [Optionals](#optionals)
 23 |   * [Type Casting](#type-casting)
 24 |   * [Struct Initializers](#struct-initializers)
 25 |   * [Shorthand](#shorthand)
 26 |   * [Typealiasing](#typealiasing)
 27 | * [Language](#language)
 28 | * [Swiftlint](#swiftlint)
 29 | * [Credits](#credits)
 30 | 
 31 | ## General
 32 | 
 33 | ### Whitespace
 34 | 
 35 | Code should be indented four spaces per indentation level.  Do not insert tab characters.
 36 | 
 37 | Files should end with a new line.
 38 | 
 39 | Calls to `super` should be followed by an empty line.
 40 | 
 41 | The closing brace for `guard` statements should be followed by an empty line.
 42 | 
 43 | ---
 44 | 
 45 | ### Braces
 46 | 
 47 | ##### Opening braces should be placed on the same line as the declaration they are encapsulating.
 48 | 
 49 | *Preferred*
 50 | ```swift 
 51 | if someCondition {
 52 |     // execute some code
 53 | }
 54 | ```
 55 | 
 56 | *Not Preferred*
 57 | ```swift
 58 | if someCondition 
 59 | {
 60 |     // execute some code 
 61 | }
 62 | ```
 63 | 
 64 | Closing braces should always be on a new line by themselves, horizontally aligned with the left edge of the opening brace it is closing.
 65 | 
 66 | *Rationale: Apple uses same line brackets in their code and Xcode autocomplete encourages it as well.*
 67 | 
 68 | ---
 69 | 
 70 | ### Control Flow
 71 | 
 72 | ##### Omit unnecessary parenthesis around control flow statements.
 73 | 
 74 | *Preferred:*
 75 | 
 76 | ```swift
 77 | while someCondition {
 78 |     // execute some code
 79 | }
 80 | ```
 81 | 
 82 | *Not Preferred:*
 83 | 
 84 | ```swift
 85 | while (someCondition) {
 86 |     // execute some code
 87 | }
 88 | ```
 89 | 
 90 | *Rationale: With braces required around bodies, the conditional part is perfectly clear without parenthesis and reads better.*
 91 | 
 92 | ---
 93 | 
 94 | ##### Prefer to `return` and `break` early.   
 95 | 
 96 | *Preferred:*
 97 | 
 98 | ```swift
 99 | guard shouldDoTheThing else {
100 |     return
101 | }
102 | 
103 | // Do the thing.
104 | ```
105 | 
106 | *Not Preferred:*
107 | 
108 | ```swift
109 | if shouldDoTheThing {
110 |     // Do the thing.  
111 | }
112 | else {
113 |     return
114 | }
115 | ```
116 | 
117 | *Rationale: This eliminates unnecessary nesting and makes the exit conditions clear up front.*
118 | 
119 | ---
120 | 
121 | ##### When using an early `return` or `break`, prefer `guard` to `if` statements.
122 | 
123 | *Preferred:*
124 | 
125 | ```swift
126 | guard shouldDoTheThing else {
127 |     return
128 | }
129 | ```
130 | 
131 | *Not Preferred:*
132 | 
133 | ```swift
134 | if !shouldDoTheThing {
135 |     return  
136 | }
137 | ```
138 | 
139 | *Rationale: The `guard` statement guarantees the early exit.  If the scope isn't exited, it will generate compile-time errors.  It is also easier for readers to identify as an early exit.*
140 | 
141 | ---
142 | 
143 | ##### Prefer using a `switch` statement over `else if` chains when dealing with enumerations.  
144 | 
145 | *Preferred:*
146 | 
147 | ```swift
148 | switch someValue {
149 | case .foo:
150 |     doFooThing()
151 | case .bar:
152 |     doBarThing()
153 | }
154 | ```
155 | 
156 | *Not Preferred:*
157 | 
158 | ```swift
159 | if someValue == MyEnum.foo {
160 |     doFooThing()
161 | }
162 | else if someValue == MyEnum.bar {
163 |     doBarThing()
164 | }
165 | ```
166 | 
167 | *Rationale: With a `switch` statement, we can more clearly distinguish whether all cases are handled.  It is also more compact.*
168 | 
169 | ---
170 | 
171 | ##### Prefer switching on tuples than unnecessary levels of nesting.
172 | 
173 | *Preferred:*
174 | 
175 | ```swift
176 | switch (someValue, direction) {
177 | case (.foo, .left):
178 |     doLeftThing()
179 | case (.foo, .right):
180 |     doRightThing()
181 | case (.bar, .left):
182 |     doBarThing()
183 | case (.bar, .right):
184 |     break       
185 | }
186 | ```
187 | 
188 | *Not Preferred:*
189 | 
190 | ```swift
191 | switch someValue {
192 | case .foo:
193 |     switch direction {
194 |     case .left:
195 |         doLeftThing()
196 |     case .right:
197 |         doRightThing()
198 |     }
199 | case .bar:
200 |     if direction == .left {
201 |         doBarThing()
202 |     }
203 | }
204 | ```
205 | 
206 | *Rationale: Switching on a tuple makes all of the possible conditions more clear from the start.  It also becomes more compact and removes unnecessary levels of nesting.*
207 | 
208 | ---
209 | 
210 | ##### Prefer starting `else` and `catch`  statements on a new line, under the closing brace for the previous statement.
211 | 
212 | *Preferred:*
213 | 
214 | ```swift
215 | do {
216 |     try doTheThing()
217 | }
218 | catch let error {
219 |     handle(error)
220 | }
221 | ```
222 | 
223 | *Not Preferred:*
224 | 
225 | ```swift
226 | do {
227 |     try doTheThing()
228 | } catch let error {
229 |     handle(error)
230 | }
231 | ```
232 | 
233 | *Rationale: Putting these statements at the beginning of a new line helps find all of the associated statements.  It also looks significantly better when collapsing code blocks in Xcode.*
234 | 
235 | ![Uncuddled](images/uncuddled.png)
236 | 
237 | ![Cuddled](images/cuddled.png)
238 | 
239 | ---
240 | 
241 | ### Loops
242 | 
243 | ##### Prefer `for`-`in` loops to `forEach` in most circumstances.
244 | 
245 | *Preferred:*
246 | 
247 | ```swift
248 | for thing in things {
249 |     thing.doTheThing()
250 | }
251 | ```
252 | 
253 | *Not Preferred:*
254 | 
255 | ```swift
256 | things.forEach { thing in
257 |     thing.doTheThing()
258 | }
259 | ```
260 | 
261 | *Rationale: The preferred style reads more naturally.*
262 | 
263 | ---
264 | 
265 | ##### When dealing with optional collections, prefer `forEach` to unwrapping.
266 | 
267 | *Preferred:*
268 | 
269 | ```swift
270 | things?.forEach {
271 |     thing.doTheThing()
272 | }
273 | ```
274 | 
275 | *Not Preferred:*
276 | 
277 | ```swift
278 | if let things = things {
279 |     for thing in things {
280 |         thing.doTheThing()
281 |     }
282 | }
283 | ```
284 | 
285 | *Rationale: While the `for`-`in` loop reads more naturally, using `forEach` to prevent unnecessary levels of nesting helps keep the overall code more readable.*
286 | 
287 | ---
288 | 
289 | ##### When the loop body is nothing but passing each item in the loop into a closure, function, or method, prefer `forEach`.
290 | 
291 | *Preferred:*
292 | 
293 | ```swift
294 | things.forEach(handleTheThing)
295 | ```
296 | *Not Preferred:*
297 | 
298 | ```swift
299 | for thing in things {
300 |     handleTheThing(thing)
301 | }
302 | ```
303 | 
304 | *Rationale: This is more compact, and passing closure arguments into methods that expect closures should feel perfectly natural in Swift.*
305 | 
306 | ---
307 | 
308 | ##### Prefer iterating over an array slice to any other sort of logic to deal with a specific section of an array.
309 | 
310 | *Preferred:*
311 | 
312 | ```swift
313 | for thing in things[first...last] {
314 |     thing.doTheThing()
315 |     handleTheThing(thing)
316 | }
317 | ```
318 | 
319 | *Not Preferred:*
320 | 
321 | ```swift
322 | for index in first.stride(through: last, by: 1)
323 |     let thing = things[index]
324 |     thing.doTheThing()
325 |     handleTheThing(thing)
326 | }
327 | ```
328 | 
329 | *Rationale: In almost all cases, iterating over the array slice will be both more compact source code and more efficient.*
330 | 
331 | ---
332 | 
333 | ##### Prefer not to pull items out of an array index within a loop.  If the `index` is needed, use the `enumerated()` method.
334 | 
335 | *Preferred:*
336 | 
337 | ```swift
338 | for (index, thing) in things.enumerated() {
339 |     print("Found \(thing) at index \(index)")
340 | }
341 | ```
342 | 
343 | *Not Preferred:*
344 | 
345 | ```swift
346 | for index in 0..<things.count {
347 |     print("Found \(things[index]) at index \(index)")
348 | }
349 | ```
350 | 
351 | ## Classes and Structures
352 | 
353 | When deciding between using a class or a struct, it is important to keep in mind that structs are value types and classes are reference types.  We need to understand the implications of using a value type versus a reference type when deciding what type to use.  
354 | 
355 | As a general rule, using structs will be safer when passing the data to multiple sources or when dealing with a multithreaded environment.  Because structs are a value type, their value is copied, so they cannot be mutated outside of the scope they are used in.  With structs, there is far less need to worry about memory leaks or race conditions.
356 | 
357 | However, because structs are value types, there is a performance hit when passing large structs around.  The larger the struct, the more data needs to be copied when we pass it.  Because classes are reference types, we are only passing a pointer to that class, so the performance is the same when passing classes, no matter the size of the class.  
358 | 
359 | However, we should be careful not to default to choosing classes for this reason alone.  The memory issues and potential for race conditions that we have to deal with and protect against with classes is arguably harder to debug and resolve.  And we shouldn't optimize for performance until performance has been measured and proven to be a problem.
360 | 
361 | It is often best to default to structs, only falling back to classes when you specifically require the functionality they provide (i.e. multiple references to the same object). This is due to struct's overall greater safety and efficiency. However, it is also important to understand the use cases for both.  While structs and classes are overall very similar, structs are more-so designed to encapsulate a small amount of values while classes are well-suited to represent custom data constructs and when you wish to represent or link to an external resource (such as files or services.)  And keep in mind with protocols & protocol extensions, we can deal with a lot of inheritance semantics even with structs.
362 | 
363 | ---
364 | 
365 | ##### Avoid explicit use of `self` except where required.
366 | 
367 | *Preferred:*
368 | 
369 | ```swift
370 | func setUpUI() {
371 |     view.backgroundColor = UIColor.blue()
372 | }
373 | ```
374 | 
375 | *Not Preferred:*
376 | 
377 | ```swift
378 | func setUpUI() {
379 |     self.view.backgroundColor = UIColor.blue()
380 | }
381 | ```
382 | 
383 | *Rationale: Omitting `self` allows for more concise code.  Only use it when a local variable has hidden an instance variable or in escaping closures.*
384 | 
385 | ---
386 | 
387 | ## Closures
388 | 
389 | ##### When calling a method with a single closure as the last argument, leave it outside the parenthesis.
390 | 
391 | *Preferred:*
392 | 
393 | ```swift
394 | UIView.animate(withDuration: animationDuration) {
395 |     self.myView.alpha = 0
396 | }
397 | ```
398 | 
399 | *Not Preferred:*
400 | 
401 | ```swift
402 | UIView.animate(withDuration: animationDuration, animations: {
403 |     self.myView.alpha = 0
404 | })
405 | ```
406 | 
407 | *Rationale: By leaving the closure out of the parenthesis, it makes the code cleaner.  This style also allows the creation of functions that look & feel like extensions of the Swift language itself.*
408 | 
409 | ---
410 | 
411 | ##### When calling a method with multiple closure arguments, include all of the closures within the parenthesis.
412 | 
413 | *Preferred:*
414 | 
415 | ```swift
416 | UIView.animate(withDuration: animationDuration, animations: {
417 |         self.myView.alpha = 0
418 |     },
419 |     completion: { _ in
420 |         self.myView.removeFromSuperview()
421 |     }
422 | )
423 | ```
424 | 
425 | *Not Preferred:*
426 | 
427 | ```swift
428 | UIView.animate(withDuration: animationDuration, animations: {
429 |         self.myView.alpha = 0
430 |     }) { _ in
431 |         self.myView.removeFromSuperview()
432 | }
433 | ```
434 | 
435 | *Rationale: The `}) {` syntax can be very confusing, and this makes the code slightly less readable compared to passing both closures in with their named arguments.  In general, we should simply prefer to avoid functions that take multiple closures, where possible.*
436 | 
437 | ---
438 | 
439 | ##### For single expression arguments, use implicit returns if the context is clear.
440 | 
441 | *Preferred:*
442 | 
443 | ```swift
444 | let filteredRestaurants = restaurants.filter { $0.id == searchID }
445 | ```
446 | 
447 | *Not Preferred:*
448 | 
449 | ```swift
450 | let filteredRestaurants = restaurants.filter { restaurant in
451 |     return restaurant.id == searchID
452 | }
453 | ```
454 | 
455 | *Rationale: When the context is clear, the implicit return allows more compact code without sacrificing any readability.*
456 | 
457 | ## Types
458 | 
459 | ##### Let Swift implicitly decide which type to use except when you require a type different from Swift's default inference.
460 | 
461 | *Preferred:*
462 | 
463 | ```swift
464 | let count = 100
465 | let width: CGFloat = 80.0
466 | let name = person.name
467 | ```
468 | 
469 | *Not Preferred:*
470 | 
471 | ```swift
472 | let count: Int = 100
473 | let width: CGFloat = 80.0
474 | let name: String = person.name
475 | ```
476 | 
477 | *Rationale: Swift type inference system is well documented.  Adding types where unnecessary adds clutter to the source code.*
478 | 
479 | ---
480 | 
481 | ##### Prefer Swift native types to Objective-C's types.
482 | 
483 | *Preferred:*
484 | 
485 | ```swift
486 | var people = [Person]()
487 | ```
488 | 
489 | *Not Preferred:*
490 | 
491 | ```swift
492 | var people = NSMutableArray()
493 | ```
494 | 
495 | *Rationale: In the case of collections, preferring Swift-native types allows for more type-safety, one of the biggest advantages Swift has over Objective-C.  In the case of other types, Swift is optimized for its native types.  Almost (if not all) of the behavior is bridged across both types, and whenever you absolutely must have the Objective-C type, you can freely cast into it.*
496 | 
497 | ---
498 | 
499 | ### Constants
500 | 
501 | ##### Prefer constants to variables.  Use `let` as your default declaration keyword, and only change to `var` when you know the value of a variable will change.
502 | 
503 | *Preferred:*
504 | 
505 | ```swift
506 | let minimumPasswordLength: Int
507 | ```
508 | 
509 | *Not Preferred:*
510 | 
511 | ```swift
512 | var minimumPasswordLength: Int
513 | ```
514 | 
515 | *Rationale: Using `let` for variables which should not change can prevent bugs and keep the code's intent more clear.*
516 | 
517 | ---
518 | 
519 | ### Optionals
520 | 
521 | ##### Avoid implicitly unwrapped optionals.
522 | 
523 | *Preferred:*
524 | 
525 | ```swift
526 | var profilePicture: UIImage?
527 | ```
528 | 
529 | *Not Preferred:*
530 | 
531 | ```swift
532 | var profilePicture: UIImage!
533 | ```
534 | 
535 | *Rationale: Implicitly unwrapped optionals can lead to [all sorts of problems](https://metova.com/blog/dev/problem-implicitly-unwrapped-optionals/) and crashes.  A little bit of extra unwrapping code is worth knowing that you won't see crashes from unwrapping `nil`.*
536 | 
537 | ---
538 | 
539 | ##### Do not force unwrap optionals.  If crashing *is* the correct behavior when the optional is `nil`, prefer a `fatalError` with a message.
540 | 
541 | *Preferred:*
542 | 
543 | ```swift
544 | guard let unwrapped = someOptional else {
545 |     fatalError("Some helpful debugging message describing the circumstance.")
546 | }
547 | ```
548 | 
549 | *Not Preferred:*
550 | 
551 | ```swift
552 | let unwrapped = someOptional!
553 | ```
554 | 
555 | *Rationale: An extra line of code here can save plenty of headaches when debugging.*
556 | 
557 | ---
558 | 
559 | ##### If a value should never be `nil`, prefer a non-optional.
560 | 
561 | *Preferred:*
562 | 
563 | ```swift
564 | class Person {
565 |     let name: String
566 | }
567 | ```
568 | 
569 | *Not Preferred:*
570 | 
571 | ```swift
572 | class Person {
573 |     // name should never be nil
574 |     var name: String?
575 | }
576 | ```
577 | 
578 | *Rationale: Using optionals for values that really never should be `nil` makes code unclear.  It can lead to bugs or crashes, and it makes it harder for other devs to understand your code.  Also, using optionals has an added unwrapping overhead.  Using optionals for values that should never be `nil` is usually a sign of problems elsewhere in the code.*
579 | 
580 | ---
581 | 
582 | ##### When you need to unwrap an optional into a non-constant, prefer `if var` and `guard var`.
583 | 
584 | *Preferred:*
585 | 
586 | ```swift
587 | if var volume = volume {
588 |     // use mutable volume
589 | }
590 | ```
591 | 
592 | *Not Preferred:*
593 | 
594 | ```swift
595 | if let volume = volume {
596 |     var vol = volume
597 |     // use mutable vol
598 | }
599 | ```
600 | 
601 | *Rationale: Using `if var` and `guard var` prevents muddying the current scope with unnecessary variable declarations.*
602 | 
603 | ---
604 | 
605 | ##### When you need to unwrap a variable from a higher scope, prefer simply shadowing the variable name.
606 | 
607 | *Preferred:*
608 | 
609 | ```swift
610 | var imageURL: URL?
611 | 
612 | // later...
613 | guard let imageURL = imageURL else { /*...*/ }
614 | ```
615 | 
616 | *Not Preferred:*
617 | ```swift
618 | var imageURL: URL?
619 | 
620 | // later...
621 | guard let unwrappedImageURL = imageURL else { /*...*/ }
622 | ```
623 | 
624 | *Rationale: This prevents cluttering the current scope with more any more variables than we actually need, and makes the code slightly easier to read.*
625 | 
626 | ---
627 | 
628 | ##### When unwrapping multiple variables, prefer the same `if let` or `guard let` clause.
629 | 
630 | *Preferred:*
631 | 
632 | ```swift
633 | if let person = people.first, let profileImageURL = person.profileImageURL {
634 |     // do something with profileImageURL
635 | }
636 | ```
637 | 
638 | *Not Preferred:*
639 | 
640 | ```swift
641 | if let person = people.first {
642 |     if let profileImageURL = person.profileImageURL {
643 |         // do something with profileImageURL
644 |     }
645 | }
646 | ```
647 | 
648 | *Rationale: This prevents unnecessary levels of nesting and helps avoid "arrow code".*
649 | 
650 | ---
651 | 
652 | ### Type Casting
653 | 
654 | ##### Do not force cast. If crashing *is* the correct behavior when a type cast fails, prefer a `fatalError` with a message.
655 | 
656 | *Preferred:*
657 | 
658 | ```swift
659 | guard let firstName = json["first_name"] as? String else {
660 |     fatalError("Some helpful debugging message describing the circumstance.")
661 | }
662 | ```
663 | 
664 | *Not Preferred:*
665 | 
666 | ```swift
667 | let firstName = json["first_name"] as! String
668 | ```
669 | 
670 | *Rationale: An extra line of code here can save plenty of headaches when debugging.*
671 | 
672 | ---
673 | 
674 | ### Struct Initializers
675 | 
676 | ##### Prefer native Swift initializers over the legacy C "make" functions.
677 | 
678 | *Preferred:*
679 | 
680 | ```swift
681 | let bounds = CGRect(x: 0, y: 0, width: 100, height: 80)
682 | let center = CGPoint(x: 50, y: 50)
683 | ```
684 | 
685 | *Not Preferred:*
686 | 
687 | ```swift
688 | let bounds = CGRectMake(0, 0, 100, 80)
689 | let center = CGPointMake(50, 50)
690 | ```
691 | 
692 | *Rationale: The named parameters of the Swift initializers make it clear which argument is which, making the code more readable.  This will also be consistent with how we initialize all of our other custom structs.*
693 | 
694 | ---
695 | 
696 | ### Shorthand
697 | 
698 | ##### Prefer more concise type declarations.
699 | 
700 | *Preferred:*
701 | 
702 | ```swift
703 | var people = [Person]()
704 | ```
705 | 
706 | *Not Preferred:*
707 | 
708 | ```swift
709 | var people: Array<Person> = Array<Person>()
710 | ```
711 | 
712 | *Rationale: The more compact version is easier to read, and no information is lost.*
713 | 
714 | ---
715 | 
716 | ### Typealiasing
717 | 
718 | ##### Use typealiases to make your code more clear.  This is especially true when dealing with units of measure.
719 | 
720 | *Preferred:*
721 | 
722 | ```swift
723 | typealias Miles = Double
724 | 
725 | func travel(distance: Miles) {}
726 | ```
727 | 
728 | *Not Preferred:*
729 | ```swift
730 | func travel(distance: Double) {}
731 | ```
732 | 
733 | *Rationale: Using typealiases makes our code self-documenting.  In the above example, without the `typealias`, it could be hard to figure out whether we're passing in the correct unit of measure, or whether we need to do a conversion before calling the method.  With the `typealias`, it is made clear that we must pass `distance` in as a measure of `Miles`.*
734 | 
735 | ## Language
736 | 
737 | ##### Code should be written in US English.
738 | 
739 | *Preferred:*
740 | 
741 | ```swift
742 | var color: UIColor
743 | ```
744 | 
745 | *Not Preferred:*
746 | 
747 | ```swift
748 | var colour: UIColor
749 | ```
750 | 
751 | *Rationale: For consistency with the existing frameworks we use in iOS development, we should use the American spellings.*
752 | 
753 | ## Swiftlint
754 | 
755 | Metova uses [swiftlint](https://github.com/realm/SwiftLint) to enforce as much of this style guide as possible across all Swift projects.  This repository also contains [the swiftlint configuration](.swiftlint.yml) file Metova uses for its projects.  
756 | 
757 | ## Credits
758 | 
759 | This style guide is a collaborative effort from members of the [Metova](https://metova.com) iOS team.
760 | 
761 | * [Nick Griffith](https://github.com/nhgrif) - Original author of this document
762 | * [Logan Gauthier](https://github.com/lgauthier) - Primary maintainer of Metova's original Swift style guide
763 | * [Chris Dillard](https://github.com/cdillard) - Primary SwiftLint resource for Metova
764 | * [Kyle Bashour](https://github.com/kylebshr) - Primary author of Metova's original Swift style guide
765 | 
766 | You can find [the Metova Team on Stack Overflow](http://stackoverflow.com/teams/68/metova).
767 | 


--------------------------------------------------------------------------------
/images/cuddled.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/metova/swift-style-guide/7fe3f6f066e3c24f9f6feb475d38df4a5d026f97/images/cuddled.png


--------------------------------------------------------------------------------
/images/metova.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/metova/swift-style-guide/7fe3f6f066e3c24f9f6feb475d38df4a5d026f97/images/metova.png


--------------------------------------------------------------------------------
/images/uncuddled.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/metova/swift-style-guide/7fe3f6f066e3c24f9f6feb475d38df4a5d026f97/images/uncuddled.png


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