Bad Cocoa

Bad Cocoa

How-to guide for building the kind of code you will deeply regret later

B5ff8c85fb809e9966436593b40f1063?s=128

Delisa Mason

May 28, 2014
Tweet

Transcript

  1. Bad Cocoa How to write the code of deep regret

    quickly and easily - @kattrali
  2. Think Monolithic ensure changing one part of an app requires

    changing them all
  3. Long Selector is Best Selector

  4. Test Private Stuff ensure every test will break during refactors

    maximize the number of mocks, stubs, and performSelector() calls
  5. Do Not Write Tests no worries, the compiler will catch

    your bugs
  6. Use Delegates with Callbacks If you don't need asynchronous callbacks

    for synchronous code, you aren't trying hard enough -initWithDelegate:callback:
  7. Subclass Subclass Subclass things will be easy when you need

    to swap out superclasses sometime!
  8. Categoriception Extend your own classes with several categories instead of

    containing each unit of related functionality in a single class
  9. Maximize Responsibilities Per Class ensure the difficulty of changing individual

    components later
  10. Safely assign many responsibilities using protocols @class MyController : NSObject

    <MyControllerDelegate, Why, God, Please, Stop, WithTheProtocols>
  11. Safely assign many responsibilities using protocols BONUS: Make each component

    of a protocol optional, for maximum flexibility and verbosity (and less warnings!!)
  12. Procrastinate on Performance always wait until you have a problem

    before opening Instruments.app
  13. if (@"Avoid Static Analysis") goto fail; goto fail;

  14. Always Swing the Heaviest Hammer NSOperation and Core Data all

    day every day - maximize boilerplate code (GCD and NSCoding don't real)
  15. Make Code Styles Inconsistent increase the difficulty of using or

    extending your project avoid code style tools like clang- format and Uncrustify
  16. Do not write documentation especially avoid easy-to-use tooling like appledoc

  17. Optimize early Reduce duplication as soon as possible, making code

    less flexible later
  18. When in doubt, add to AppDelegate There is no better

    place to dump bits of code which do not belong anywhere and need access to application state certainly not new classes
  19. #define over static variables get the most of your available

    memory for your numbers, strings, and colors
  20. Thank you!