Updated presentation for the Houston iPhone Dev User Group

Transcript

1. Tailor your Swift Hand-crafting code as an Apple Developer
2. Swift What does it have?
3. Has all the things properties, optionals classes, structs, enums (super-powerful) blocks (with lamba-expression syntax) protocols (interfaces) class and protocol extensions generics
4. Can do all the things Object-oriented Functional Programming High performance Easier to read syntax Protocol oriented Robust compile time checking (without building)
5. The Crux Why is writing better code important?
6. 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.
7. 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.
8. Clean Swift thoughtful coding in Apple’s language
9. mini methods
10. speaking of conditional statements be explicit
11. Unintended method consequences What does that have to do with populating?
12. Either name it properly or move it out • It’s clear that if a new form condition holds, 2 things need to be done. • prepopulateForm( ) is back to doing 1 job. • It easy, lazy and dangerous to add new code inside a method that had a different purpose.
13. Prefer Swift’s method naming conventions methods should read like human speech
14. Like a book. Group sentences into thoughts, or paragraphs
15. Remember, you’re making code easier to read for yourself as well as others.
16. Use , instead of && only applies to if/else statements still need || if you want to OR
17. unwrapping optionals
18. 1) 2) unwrap and add a conditional
19. 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
20. optionals continued.
21. community agreement on optional unwrapping • prefer to use the same name as the optional, or “same- name shadowing” per Erica Sadun. • 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.
22. don’t return an optional just because you can
23. Super-powered Enums More than just mutually-exclusive conditions
24. Super-powered Enums too many ifs
25. Use when your type can represent “states” in an “or” relationship, but still needs data associated with each state.
26. cleaner creation cleaner usage
27. An alternative to subclassing
28. The classic problem • Subclassing is great until it is overused and no longer makes sense • Derived types start taking on too many unique behaviors. • Historically you’d use composition in other languages to prevent subclassing.
29. Associated values again
30. When to use what • Subclassing is useful when you have a hierarchal design that you don’t anticipate changing very much. • If your types can be light-weight structs, use an enum with associated values. • Mix in some protocols to promise behavior. (protocol-based programming)
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. Continue reading
47. Thank you!