draft.txt

メンテナンス性の高い iOS アプリを書こう

下書きの殴り書き
あとで清書してタイトル釣り気味にしつつ、書き出しの序文で「これ読んで「知らなかった！」「勉強になる」とかコメント付けたりはてブする人間とは一緒に仕事出来る気がしない」みたいな煽り文句付けたい

---

ググれ
でも情報にノイズが多い
日本語のブログ記事みたいなの、はてブ系や自分のハンドルネームのドメインで運用してるもの以外、アメブロとかそういうのに書いてるのは信用しない方がいい場合が多い
困ったときのスタックオーバーフロー
というかググる前にリファレンス引け
Xcode の cmd + shift + 2 から行くか素直に Dash

不必要な情報を .h に書くな
IBOutlet や import は .m に書け
ヘッダに出すメソッドに型の明示が必要なら class とか protcol の前方宣言しろ
synthesize 書くな
インスタンス変数は _ から始めろ

ファイルスコープの static 変数は __ から始めるみたいなことしてる

Cocoa の命名規則に従え
内部状態が変わるのは動詞から
というか動詞から始まらないメソッド名で外から見て不都合があるような内部状態の変更をするな（変えるなとは言わん）
返り値が void でないなら型からプレフィックスを除いた名詞で始まるメソッド名に書け
引数あるなら名前までわかるようなメソッド名
delegate メソッド過去形と現在形が同じ動詞だと困るから did will とかちゃんと付けろ
というか delegate メソッドに限らず英語的に不自然でも did will 付けた方が分かりやすくなる場合もある
単純な getter に見えるメソッドで重たいループ回すな。回す必要があるなら管理されたキャッシュ機構作れ

NSObject を始め UIViewController やら UIView やら UIResponder やらの、システムから呼ばれる系メソッドの呼ばれるタイミングをちゃんと知っておけ
- layoutSubviews とか - didAddSubview とか
- awakeFromNib とか + load とか + initialize とか

マルチタッチからの連打されても不都合ないように作れ
UIControl とか UIGestureRecognizer と友達になれ

NSLog() を直で使うな。#ifdef DEBUG #endif で囲うなりしろ
そもそも NSLog() 重たいから連続で呼ばれる系のところでは目に見えてパフォーマンス低下するし、出しすぎるとまさかの母艦の方に swap 発生しまくりで死ぬ

pragma mark - で区切れ

StoryBoard 破滅しがちなので xib を適切に使う
xib の owner とかちゃんと指定してコーディング量を減らせ
UITableView に registerNib すると cell を共通化しやすい

当たり前だけどコピペすることになりそうならくくりだせ
決め打ちの数値があるなら "尚更" 名前を付けて static const な定数にしろ

C の知識を持とう
static const 修飾子の挙動と付けていい場所悪い場所
適宜キャストしろ
enum よりは NS_ENUM NS_OPTIONS などを使え
標準関数知っとけ fabs() とか ceil() とか floor() とか round() とか rand() とか
rand() で思ったけど乱数使うときは一応その乱数が本当に一様分布するのかみたいなこと考えろ
計算量のこと考えろ
コンピュータサイエンス
自分で平衡二分探索木の実装出来る必要はないと思うけど使う関数の計算量とアルゴリズムの特性は知っておけ
alloc 系はコスト高い

Blocks 便利
__weak 便利
dispatch 名前がかっこいい
UI 更新にメインスレッドへとりあえず感覚で dispatch
低レイヤなフレームワーク使ったりしたり NSNotificationCenter から呼ばれたりするのがメインスレッドでない場合がたまにある
performSelector:withObject:afterDelay: と NSObject cancelPreviousPerformRequestsWithTarget:selector:object: が便利なこともある

#define より static NSString* const

https://github.com/NYTimes/objective-c-style-guide

- description メソッドを書け
static analyzer 使え