Intro to Swift and clean coding practices

Transcript

1. Tailor your Swift
   Hand-crafting code as an Apple Developer
   

   View Slide

2. Swift
   What does it have?
   

   View Slide

3. All the things
   properties, optionals
   classes, structs, enums (super-powerful)
   blocks (with lamba-expression syntax)
   protocols (interfaces)
   class and protocol extensions
   generics
   

   View Slide

4. Properties
   stored
   computed
   lazy
   

   View Slide

5. read-only
   lazy with more
   observers
   

   View Slide

6. Properties
   wrappers
   

   View Slide

7. Methods
   uniquely Swift
   

   View Slide

8. Classes
   - can inherit from only 1 subclass
   
   - can implement 1 to many protocols (interfaces)

   - the usual reference type behavior
   

   View Slide

9. Structs
   - cannot inherit from another struct or class
   
   - can implement 1 to many protocols (interfaces)

   - the usual value type behavior
   

   View Slide

10. When to use what
    - when you need to inherit, use a class.
    
    - when your type has utility methods, holds
    properties (like a model object), etc. make it a
    struct.

    - Immutability should be preferred, thus prefer
    structs and use a class only when it’s necessary.
    

    View Slide

11. Enums
    associated values
    can declare a type and raw values
    

    View Slide

12. Blocks
    

    View Slide

13. Protocols
    

    View Slide

14. Optionals
    It’s there or it’s not
    

    View Slide

15. The Crux
    Why is writing better code important?
    

    View Slide

16. The complex programmer
    • writes cryptic, complex code
    because they can.
    • never reads programming books
    or attends meetups, code
    confs. etc.
    • no documentation, if you can’t
    read it, you’re just a bad
    developer.
    • basically a ‘lifer’ at the
    business.
    

    View Slide

17. The thoughtful programmer
    • writes clean, patterned and thoughtful code.
    • always strives for improvement and not for the
    sake of making more money.
    • documents code with proper naming, patterns
    and comments.
    • uses peer-reviewed pull requests to learn from
    his mistakes.
    

    View Slide

18. Clean Swift
    thoughtful coding in Apple’s language
    

    View Slide

19. mini methods
    

    View Slide

20. speaking of conditional statements
    be explicit
    

    View Slide

21. Prefer Swift’s method naming conventions
    methods should read like human speech
    

    View Slide

22. Remember, you’re
    making code easier to
    read for yourself as well
    as others.
    

    View Slide

23. Use , instead of &&
    only applies to if/else statements
    still need || if you want to OR
    

    View Slide

24. unwrapping optionals
    

    View Slide

25. 1)
    2)
    unwrap and add a conditional
    

    View Slide

26. clean up optionals with guard
    • early termination (no need to carry on if
    conditions aren’t met).
    • cleans by removing if let optional bindings and
    conditional statements
    

    View Slide

27. optionals continued.
    

    View Slide

28. community agreement on optional
    unwrapping
    • prefer to use the same name as the optional.
    • the compiler has no issues, and it will only be local to the
    method.
    • The same goes for guard, use the optional’s name for the
    unwrapped type.
    

    View Slide

29. don’t return an optional just
    because you can
    

    View Slide

30. Like a book.
    Group sentences into thoughts, or paragraphs
    

    View Slide

31. assert yourself
    • 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 with error reporting and/or add to them
    with an assertFailure
    

    View Slide

32. • A great place to use them is in fail early guard
    statements.
    • They are stripped out for a release build
    (assuming you’re using different builds).
    • fail early and stop to solve bugs during
    development and not from a QA bug ticket.
    

    View Slide

33. I see dead comments
    • Comments are part of the code, treat them as such
    • The less noticeable they are, the more likely they’ll
    go unmaintained
    • Change their color to stand out more
    • Pay attention to comments in pull requests.
    

    View Slide

34. Take care of warnings
    • _ = lets you suppress the unused result warning,
    and explicitly tells the reader “I am intentionally
    ignoring this returned value.”
    • Follow Xcode’s instructions or fix the code to make
    the warning go away
    • Sign of a broken-window-theory project are
    hundreds of warnings.
    

    View Slide

35. ViewControllers
    MVC
    ?
    Massive-View-Controller
    

    View Slide

36. The problem
    

    View Slide

37. Start cleaning
    • Add a (pragma) mark above every set of protocol code (for each)
    • This gives you a nice visual divider in the code and the
    quick search drop-down
    

    View Slide

38. Extract and extend
    take the code out of the VC and add an extension
    • naming convention: className+protocol.swift
    • technically it’s still a part of the class but it reduces
    the size of the class and organizes the code better.
    

    View Slide

39. Lighten the load
    use the coordinator pattern for viewControllers
    • The heart of the problem is that segues and
    navigation are usually implemented in the view
    controllers.
    • This tightly couples 1 view controller to another.
    • Remove this responsibility with a Coordinator
    

    View Slide

40. Coordinate
    everything in software should have 1 job.
    • Every view controller gets a coordinator
    • All vc coordinators are controlled by an AppCoordinator
    • Makes the ViewControllers do only what they’re supposed to, update
    the view.
    • Segues are negated, as the coordinators now control the navigation
    and app workflow
    

    View Slide

41. ViewCoordinator
    

    View Slide

42. Coordinator Tutorial
    https://www.raywenderlich.com/158-coordinator-tutorial-for-ios-getting-started
    

    View Slide

43. Protocol based
    

    View Slide

44. Core Data
    manage model objects as protocols
    

    View Slide

45. Prefer protocols
    • Apple strongly suggests protocol-based development
    and you see it through out CocoaTouch.
    • Protocols let you swap out dependencies easily at
    run-time.
    • Coordinators can hold onto these protocol-based
    dependencies instead of ViewControllers.
    • Protocols enforce the you-have-1-job rule better.
    

    View Slide

46. Thank you!
    

    View Slide