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
410
AppKit for iOS Developers
kattrali
5
850
Crafting iOS Dev Tools in Redcar, the Ruby Editor
kattrali
2
740
Other Decks in Programming
See All in Programming
RuboCop: Modularity and AST Insights
koic
2
2.1k
By the way Google Cloud Next 2025に行ってみてどうだった
ymd65536
0
110
個人開発の学生アプリが企業譲渡されるまで
akidon0000
0
1.1k
音声プラットフォームのアーキテクチャ変遷から学ぶ、クラウドネイティブなバッチ処理 (20250422_CNDS2025_Batch_Architecture)
thousanda
0
350
Amazon CloudWatchの地味だけど強力な機能紹介!
itotsum
0
200
「影響が少ない」を自分の目でみてみる
o0h
PRO
2
1.2k
Thank you <💅>, What's the Next?
ahoxa
1
570
AIコーディングの理想と現実
tomohisa
33
36k
PHP で学ぶ OAuth 入門
azuki
1
220
Ruby's Line Breaks
yui_knk
3
2k
Instrumentsを使用した アプリのパフォーマンス向上方法
hinakko
0
140
Java 24まとめ / Java 24 summary
kishida
3
510
Featured
See All Featured
Visualization
eitanlees
146
16k
Done Done
chrislema
184
16k
Adopting Sorbet at Scale
ufuk
76
9.3k
Designing for humans not robots
tammielis
253
25k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Become a Pro
speakerdeck
PRO
28
5.3k
A designer walks into a library…
pauljervisheath
205
24k
Faster Mobile Websites
deanohume
306
31k
How to Ace a Technical Interview
jacobian
276
23k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.8k
Testing 201, or: Great Expectations
jmmastey
42
7.5k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
2.9k
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!