([Any] vs Array<Any>) •Prefer Generic form if you need to specify where Sugar inference doesn’t work (Set<Any> for instance) •The community at large seems to prefer [AnyHashable:Any] over Dictionary<,>, so it is what it is.
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
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
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
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
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
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.
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