Intro to Swift and clean coding practices

Intro to Swift and clean coding practices

9949ea4cd54bd477e21ab3273a7b7186?s=128

Mark Wilkinson

February 05, 2020
Tweet

Transcript

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

  2. Swift What does it have?

  3. All the things properties, optionals classes, structs, enums (super-powerful) blocks

    (with lamba-expression syntax) protocols (interfaces) class and protocol extensions generics
  4. Properties stored computed lazy

  5. read-only lazy with more observers

  6. Properties wrappers

  7. Methods uniquely Swift

  8. Classes - can inherit from only 1 subclass - can

    implement 1 to many protocols (interfaces)
 - the usual reference type behavior
  9. Structs - cannot inherit from another struct or class -

    can implement 1 to many protocols (interfaces)
 - the usual value type behavior
  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.
  11. Enums associated values can declare a type and raw values

  12. Blocks

  13. Protocols

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

  15. The Crux Why is writing better code important?

  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.
  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.
  18. Clean Swift thoughtful coding in Apple’s language

  19. mini methods

  20. speaking of conditional statements be explicit

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

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

    well as others.
  23. Use , instead of && only applies to if/else statements

    still need || if you want to OR
  24. unwrapping optionals

  25. 1) 2) unwrap and add a conditional

  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
  27. optionals continued.

  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.
  29. don’t return an optional just because you can

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

  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
  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.
  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.
  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.
  35. ViewControllers MVC ? Massive-View-Controller

  36. The problem

  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
  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.
  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
  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
  41. ViewCoordinator

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

  43. Protocol based

  44. Core Data manage model objects as protocols

  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.
  46. Thank you!