Thursday 8 September 2011

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!

No comments: