Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
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
420
AppKit for iOS Developers
kattrali
5
870
Crafting iOS Dev Tools in Redcar, the Ruby Editor
kattrali
2
790
Other Decks in Programming
See All in Programming
GISエンジニアから見たLINKSデータ
nokonoko1203
0
140
20251212 AI 時代的 Legacy Code 營救術 2025 WebConf
mouson
0
180
まだ間に合う!Claude Code元年をふりかえる
nogu66
5
850
TUIライブラリつくってみた / i-just-make-TUI-library
kazto
1
390
マスタデータ問題、マイクロサービスでどう解くか
kts
0
110
関数実行の裏側では何が起きているのか?
minop1205
1
710
MAP, Jigsaw, Code Golf 振り返り会 by 関東Kaggler会|Jigsaw 15th Solution
hasibirok0
0
250
ELYZA_Findy AI Engineering Summit登壇資料_AIコーディング時代に「ちゃんと」やること_toB LLMプロダクト開発舞台裏_20251216
elyza
1
240
ViewファーストなRailsアプリ開発のたのしさ
sugiwe
0
490
DevFest Android in Korea 2025 - 개발자 커뮤니티를 통해 얻는 가치
wisemuji
0
150
AIエージェントを活かすPM術 AI駆動開発の現場から
gyuta
0
430
Flutter On-device AI로 완성하는 오프라인 앱, 박제창 @DevFest INCHEON 2025
itsmedreamwalker
1
120
Featured
See All Featured
Become a Pro
speakerdeck
PRO
31
5.7k
Why Our Code Smells
bkeepers
PRO
340
57k
Docker and Python
trallard
47
3.7k
The Pragmatic Product Professional
lauravandoore
37
7.1k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
37
6.2k
What's in a price? How to price your products and services
michaelherold
246
13k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
122
21k
The Language of Interfaces
destraynor
162
25k
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
Java REST API Framework Comparison - PWX 2021
mraible
34
9k
Leading Effective Engineering Teams in the AI Era
addyosmani
9
1.3k
Balancing Empowerment & Direction
lara
5
800
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!