Has all the things properties, optionals classes, structs, enums (super-powerful) blocks (with lamba-expression syntax) protocols (interfaces) class and protocol extensions generics
Can do all the things Object-oriented Functional Programming High performance Easier to read syntax Protocol oriented Robust compile time checking (without building)
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.
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.
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.
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
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.
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.
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)
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
• 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.
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.
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.
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
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.
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
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
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.
markawil
toricky6
seike460
3150
huffon
koic
okuramasafumi
ivargrimstad
hogelog
zakky21
doggy
atinfinity
takashisomeya
geeforr
thekraken
eileencodes
aarron
lara
bcantrill
bermonpainter
lemiorhan
holman
samanthasiow
tammielis
jeffersonlam