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
420
AppKit for iOS Developers
kattrali
5
860
Crafting iOS Dev Tools in Redcar, the Ruby Editor
kattrali
2
760
Other Decks in Programming
See All in Programming
AHC051解法紹介
eijirou
0
620
SOCI Index Manifest v2が出たので調べてみた / Introduction to SOCI Index Manifest v2
tkikuc
1
110
AI OCR API on Lambdaを Datadogで可視化してみた
nealle
0
180
未来を拓くAI技術〜エージェント開発とAI駆動開発〜
leveragestech
2
180
なぜ今、Terraformの本を書いたのか? - 著者陣に聞く!『Terraformではじめる実践IaC』登壇資料
fufuhu
4
650
コンテキストエンジニアリング Cursor編
kinopeee
1
700
WebAssemblyインタプリタを書く ~Component Modelを添えて~
ruccho
1
910
兎に角、コードレビュー
mitohato14
0
150
物語を動かす行動"量" #エンジニアニメ
konifar
14
5.4k
Portapad紹介プレゼンテーション
gotoumakakeru
1
130
The state patternの実践 個人開発で培ったpractice集
miyanokomiya
0
150
AWS Serverless Application Model入門_20250708
smatsuzaki
0
130
Featured
See All Featured
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.5k
Building Applications with DynamoDB
mza
96
6.6k
How to train your dragon (web standard)
notwaldorf
96
6.2k
Documentation Writing (for coders)
carmenintech
73
5k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
110
20k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
Code Review Best Practice
trishagee
70
19k
Java REST API Framework Comparison - PWX 2021
mraible
33
8.8k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.8k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
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!