•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.
•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
•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
•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
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.
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
• 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
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.
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
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
• 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
markawil
chimame
manfredsteyer
goutarouh
os1ma
.png){kind=avatar}
melonattacker
yahiru
knr109
akkyie
takefumiyoshii
kasacchiful
aridlehoover
assu_ming
kevinliebholz
malarkey
rmw
carmenintech
eileencodes
geeforr
jasonvnalue
ammeep
edds
bkeepers
lauravandoore
maltzj