Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Bad Cocoa
Search
Delisa Mason
May 28, 2014
Programming
12
17k
Bad Cocoa
How-to guide for building the kind of code you will deeply regret later
Delisa Mason
May 28, 2014
Tweet
Share
More Decks by Delisa Mason
See All by Delisa Mason
Pod for Great Good
kattrali
2
400
AppKit for iOS Developers
kattrali
5
820
Crafting iOS Dev Tools in Redcar, the Ruby Editor
kattrali
2
720
Other Decks in Programming
See All in Programming
42 best practices for Symfony, a decade later
tucksaun
1
180
フロントエンドのディレクトリ構成どうしてる? Feature-Sliced Design 導入体験談
osakatechlab
8
4.1k
開発者とQAの越境で自動テストが増える開発プロセスを実現する
92thunder
1
180
ソフトウェアの振る舞いに着目し 複雑な要件の開発に立ち向かう
rickyban
0
890
「とりあえず動く」コードはよい、「読みやすい」コードはもっとよい / Code that 'just works' is good, but code that is 'readable' is even better.
mkmk884
3
230
Monixと常駐プログラムの勘どころ / Scalaわいわい勉強会 #4
stoneream
0
270
DevFest Tokyo 2025 - Flutter のアプリアーキテクチャ現在地点
wasabeef
5
900
선언형 UI에서의 상태관리
l2hyunwoo
0
160
複雑な仕様に立ち向かうアーキテクチャ
myohei
0
170
テストコード文化を0から作り、変化し続けた組織
kazatohiei
2
1.5k
[JAWS-UG横浜 #76] イケてるアップデートを宇宙いち早く紹介するよ!
maroon1st
0
460
なまけものオバケたち -PHP 8.4 に入った新機能の紹介-
tanakahisateru
1
120
Featured
See All Featured
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
28
900
Side Projects
sachag
452
42k
Typedesign – Prime Four
hannesfritz
40
2.4k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
Code Reviewing Like a Champion
maltzj
520
39k
Site-Speed That Sticks
csswizardry
2
190
Building a Scalable Design System with Sketch
lauravandoore
460
33k
Building Adaptive Systems
keathley
38
2.3k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.5k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.1k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
28
8.3k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5k
Transcript
Bad Cocoa How to write the code of deep regret
quickly and easily - @kattrali
Think Monolithic ensure changing one part of an app requires
changing them all
Long Selector is Best Selector
Test Private Stuff ensure every test will break during refactors
maximize the number of mocks, stubs, and performSelector() calls
Do Not Write Tests no worries, the compiler will catch
your bugs
Use Delegates with Callbacks If you don't need asynchronous callbacks
for synchronous code, you aren't trying hard enough -initWithDelegate:callback:
Subclass Subclass Subclass things will be easy when you need
to swap out superclasses sometime!
Categoriception Extend your own classes with several categories instead of
containing each unit of related functionality in a single class
Maximize Responsibilities Per Class ensure the difficulty of changing individual
components later
Safely assign many responsibilities using protocols @class MyController : NSObject
<MyControllerDelegate, Why, God, Please, Stop, WithTheProtocols>
Safely assign many responsibilities using protocols BONUS: Make each component
of a protocol optional, for maximum flexibility and verbosity (and less warnings!!)
Procrastinate on Performance always wait until you have a problem
before opening Instruments.app
if (@"Avoid Static Analysis") goto fail; goto fail;
Always Swing the Heaviest Hammer NSOperation and Core Data all
day every day - maximize boilerplate code (GCD and NSCoding don't real)
Make Code Styles Inconsistent increase the difficulty of using or
extending your project avoid code style tools like clang- format and Uncrustify
Do not write documentation especially avoid easy-to-use tooling like appledoc
Optimize early Reduce duplication as soon as possible, making code
less flexible later
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
#define over static variables get the most of your available
memory for your numbers, strings, and colors
Thank you!