Clean Coding in Swift - Speaker Deck

Slide 1

Slide 1 text

The Swift Way clean coding

Slide 2

Slide 2 text

You’re telling a story - Daniel Steinberg

Slide 3

Slide 3 text

What’s in a good story? •Succinct Titles and Section Headers •Sentences that convey meaning. •Grouping those sentences into a thought, or a paragraph.

Slide 4

Slide 4 text

Succinct Titles and Headers (or better method signatures)

Slide 5

Slide 5 text

better methods sigs

Slide 6

Slide 6 text

pop-quiz ?

Slide 7

Slide 7 text

Not succinct

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

{ braces and (parens) } 2 styles of bracing C style (K&R) and C# (Allman)

Slide 10

Slide 10 text

{ bracing alignments } C-K&R Style C#-Allman

Slide 11

Slide 11 text

No right or wrong choice Apple and most Swift developers continue with the C-K&R style Stay consistent, don’t mix the 2

Slide 12

Slide 12 text

Speaking of alignments

Slide 13

Slide 13 text

Anyone miss this?

Slide 14

Slide 14 text

Knock yourself out (still prefer obj-c alignment of colons, but oh well)

Slide 15

Slide 15 text

Proper alignment helped readability in Objective-c and it continues to help in Swift

Slide 16

Slide 16 text

Parentheses () Hugging is best Avoid

Slide 17

Slide 17 text

Parentheses? () Avoid them when there’s only 1 condition to an if or else if

Slide 18

Slide 18 text

Statements that convey meaning

Slide 19

Slide 19 text

Convey the meaning don’t expect the reader to deduce

Slide 20

Slide 20 text

Group sentences into thoughts, or paragraphs

Slide 21

Slide 21 text

Collections: Sugar or Generics?

Slide 22

Slide 22 text

•Prefer Collection ‘Sugar’ in initializing or identifying the collection type ([Any] vs Array) •Prefer Generic form if you need to specify where Sugar inference doesn’t work (Set for instance) •The community at large seems to prefer [AnyHashable:Any] over Dictionary<,>, so it is what it is.

Slide 23

Slide 23 text

if let cascading

Slide 24

Slide 24 text

f*n awesome block syntax

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

•Embrace the closure argument sugar, avoid param names when the types are inferred •Prefer however named arguments when the implementation inside the block is nontrivial •Only use $0 when the params are worthless •Put your single closure as the last parameter to a method to get the last argument styling Erica’s rules

Slide 27

Slide 27 text

Recognition above Recall

Slide 28

Slide 28 text

on guard

Slide 29

Slide 29 text

More cleaning

Slide 30

Slide 30 text

•Replace common and (overlooked) if statements and if let pyramids with early-fail guard statements •Put multiple guard conditions on their own lines, allows breakpointing each line, commenting out conditions etc. •Even better, break each condition into it’s own guard statement

Slide 31

Slide 31 text

•The selling point of guard usage is early failure, and finding bugs during development •Pair guard with assertionFailures to find exceptions early •guard statements help reduce if-let pyramids •They let the logic in a method focus on what needs to be done instead of checking for missing/nil conditions. Use guard

Slide 32

Slide 32 text

optional unwrapping •Erica recommends not adding ‘valid’ or ‘unwrapped’ to the variable that is now valid. •This creates a scenario where validResponse might have existed somewhere else and is re-purposed •I personally keep using this style so proceed with caution.

Slide 33

Slide 33 text

clean repurpose unwrapping

Slide 34

Slide 34 text

Use assertions • assertionFailures should be used in place of many NSLog and print statements. • You the developer need to find crashing conditions early not in QA • Go through every console log (NSLog, print) and replace error reporting or add to them with an assertFailure

Slide 35

Slide 35 text

• A great place to use them is in fail early guard statements • They are of course stripped out for a release build (assuming you’re using different builds) • fail early and stop to solve failures early not at the last minute or in a bug ticket

Slide 36

Slide 36 text

Ternaries, or please stop • Ternary statements are just cryptic if-else conditions. • They can get more complex, and do nothing other than force another developer to decrypt them. • Harder to debug with breakpoints • Just refactor them out to if-else or guard statements.

Slide 37

Slide 37 text

Finalize and seal • By default you should finalize your classes • Final prevents subclassing, which is the source of endless problems in the OO world. • Tells another developer you had no intention for this class to be subclassed and overrode. • Lack of subclassing introduces better patterns like protocols and containment

Slide 38

Slide 38 text

If you have to subclass Prefer the abstract class pattern But there is no abstract keyword in Swift

Slide 39

Slide 39 text

Those pesky baseViewControllers • The most common subclass is the viewController • Usually have properties that they all need, and most commonly, error reporting and alert showing

Slide 40

Slide 40 text

Move to a protocol with extensions

Slide 41

Slide 41 text

• The ViewController is still only 1 subclass deep. • It now implements a useful protocol with extended behavior • Add new protocols with their own extensions for other specific behaviors • This prevents massive god-base-classes

Slide 42

Slide 42 text

other developers Mark Wilkinson

Slide 43

Slide 43 text

You’ll influence other developers, which in turn will influence more down the line

Slide 44

Slide 44 text

Smell the roses, not the code, embrace your personal style - Erica Sadun