iOSDev UK: Coding for your Future Self

Martin Pilkington, @pilky

• there are three you’s
  • now — doing the work
  • future — code guru
  • past — got let near your computer and vomited all over your code…
• consistent formatting — follow conventions
  • don’t fight the conventions
• composition vs subclassing
  • cocoa often better to use composition
• copy immutable classes — don’t use a reference
• don’t ship code with exceptions
  • in Objective-C they’re for invalid state — programming errors
  • use NSError instead
• naming
  • don’t abbreviate
  • no namespaces, so prefix all your classes, preferably with 3+ chars
  • prefix category methods on other classes too, e.g. abc_categoryMethod
  • capitalise acronyms
  • if last param is error return, should be error:
• if you comment every method then you’ll be in the habit of commenting when it counts
  • not sure I totally agree — comments can get out of date with the code. perhaps better to comment longer code pieces rather than each and every method
• large classes and large methods are unmaintainable
  • also splits out more stuff into back-end code
  • better for testing, better for multi-platform
• better to inject dependencies (tell, don’t ask)
  • or at least expose a property to set during tests
  • if do so, then either set default in init, or use lazy construction in the getter method
• notifications
  • can also be distributed to other devices
  • see kellabyte.com for continuous client
• regular refactoring:
  • always leave the campground cleaner than you found it
  • have spring cleaning days/hours
  • lots of little refactors mean less big rewrites!