インデントにスペースを使う。コードにはタブを使ってはいけない。 タブキーを押したときにはスペースが入力されるように、エディタを設定しておこう。

Objective-CはC++と比べて言葉が長くなりがちな言語ではあるが、C++のガイドと相互運用できるよう、C++と同じ80カラムに制限することにした。これを受け入れるのは意外と簡単なことだ。

このルールには賛否両論あると思うが、すでに既存のコードのほとんどがこれを守っているし、私たちは一貫性が重要だと思っている。

Xcodeでは、Xcode > 環境設定 > テキスト編集 > ページガイドを表示 で設定しておくことで、これに違反している場所を簡単に見つけることができる。

メソッドは次のようになるはずだ:

アスタリスク（*）の前にはスペースを入れても入れなくてもいい。コードを新しく追加するときには、まわりのファイルのスタイルに合わせること。

パラメータが多すぎて1行に収まらなければ、1行につき1つのパラメータを書くのが望ましい。複数行にわたるときには、パラメータの前にある : で整列させること。

このルールはC++の public、private、protected と同じだ。

もしObjective-Cの例外を使わなければならないなら、次のような書式にすること。しかし、例外を使うべきではない理由について、例外を投げるのをやめるを参照すること。

ファイル拡張子は次のようにするべきだ:

カテゴリのファイル名には拡張されるクラス名を含むようにするべきだ。例えば、GTMNSString+Utils.h や GTMNSTextView+Autocomplete.h。

Cocoa/Objective-CとC++が混在するときには、異なる命名スタイルが衝突してしまうのを最小限にするために、実装しようとしているメソッドのスタイルに従うこと。もし @implementation ブロックであればObjective-Cの命名規則を使うこと。もしC++の class の中にあるメソッドを実装しているのであればC++の命名規則を使うこと。

アプリケーションレベルのコードでは通常、クラス名にプレフィックスを付けるべきではない。単体のクラスすべてに同じプレフィックスを付けても、読みにくくなるだけで得られるものはない。複数のアプリケーションで共通に使うコードを設計しているときには、プレフィックスを付けるのが望ましく付けることを推奨する。（例えば、GTMSendMessage）。

例えば、NSString にパースのためのカテゴリを作成したいなら、GTMNSString+Parsing.h という名前のファイルにカテゴリを入れておく。そして、カテゴリ名を GTMStringParsingAdditions とする（もちろんファイル名とカテゴリ名が一致していないのはわかっている。でもこうすることで、このファイルにパースに関連した個別のカテゴリをいろいろと入れることができる）。同じカテゴリにあるメソッドには同じプレフィックス（gtm_myCategoryMethodOnAString:）を付けておくべきだ。こうしておくと、名前空間が1つしかないObjective-Cでも、名前の衝突を避けることができる。もしコードを共有するつもりがなかったり、別のアドレス空間で実行されるのであれば、メソッドの命名はそれほど重要ではない。

メソッド名はできるだけ文章のように読めるようにして、パラメータ名もメソッド名から続けて読めるようなものを選ぶべきだ。（例えば、convertPoint:fromRect:や replaceCharactersInRange:withString:）。詳しくはAppleによるメソッドの命名ガイドを参照すること。

アクセサメソッドは「取得しようしている」変数と同じ名前にするべきだ。"get"というプレフィックスを付けるべきではない。 - (id)getDelegate; // AVOID - (id)delegate; // GOOD

このルールはObjective-Cのメソッドにだけ適用される。C++のメソッド名や関数名はC++スタイルガイドにあるルールに従うこと。

インタフェースの詳細について、すでにファイルの先頭で説明しているのであれば、"See comment at top of file for a complete description"（「詳しくはファイル先頭のコメントを参照すること」）と書いておいても構わないが、必ず何かしらのコメントを入れておくこと。

さらに、パブリックインタフェースにあるメソッドには機能、引数、戻り値、あらゆる副作用について説明したコメントを入れておくべきだ。

もしクラスが想定している同期があれば、それについて書いておくこと。もしクラスのインスタンスが複数のスレッドからアクセスされる可能性があるのなら、マルチスレッドの利用に関するルールや不変条件を明記しておくよう十分注意すること。

こうすることであいまいさをなくすことができる。特にシンボルがよく見かける単語で、下手に文章として読めてしまうときに有効だ。 例えば、シンボル "count" の場合:

あるいは、すでに引用符が含まれているものを引用する場合:

NSObject から派生したオブジェクトを指すインスタンス変数ポインタは、保持されていると見なされる。もしそのクラスによって保持されていないのであれば、weak（弱い参照）であることを明記しておくべきだ。ただし IBOutlet というラベルの付いたインスタンス変数は、クラスによって保持されていないと見なされる。もしそのクラスによって保持されているのであれば、strong（強い参照）であることを明記しておくべきだ。

インスタンス変数が CoreFoundation や C++、Objective-C以外のオブジェクトへのポインタであるときには、strong であるか weak であるかをコメントに明記しておくべきだ。C++オブジェクトをObjective-Cオブジェクトに自動的にカプセル化する機能はデフォルトでは無効になっていることに注意しよう。これについてはここに説明がある。

strong と weak の記載例 @interface MyDelegate : NSObject { @private IBOutlet NSButton* okButton_; // normal NSControl IBOutlet NSMenu* myContextMenu_; // manually-loaded menu (strong) AnObjcObject* doohickey_; // my doohickey MyController* controller_; // so we can send msgs back (weak, owns me) // non-NSObject pointers... CWackyCPPClass* wacky_; // some cross-platform object (strong) CFDictionaryRef* dict_; // (strong) } @end

strong

オブジェクトはこのクラスによって retain されている

weak

オブジェクトはこのクラスによって retain されていない （例: デリゲート）

あなたが作ったクラスをサブクラス化しようとしている人にとって、指定イニシャライザがはっきりとわかることは重要だ。指定イニシャライザがわかれば、（複数あるかもしれない）イニシャライザのうち1つをサブクラス化することでサブクラスのイニシャライザを確実に呼び出すことができる。将来あなたが作ったクラスを誰かがデバッグしなければならないとき、クラスの初期化の流れを理解するのにも役に立つ。

スーパークラスの指定イニシャライザを上書きしていないと、イニシャライザが必ず呼び出される保証はない。これはバグを見つけるのをやっかいにして、問題を非常に難しくする。

新しく割り当てられたオブジェクトのメモリは（isa を除いて）すべて 0 に初期化される。だから 0 や nil で変数を再初期化することで、init メソッドをいっぱいにしてはいけない。

C++と違ってObjective-Cにはパブリックメソッドとプライベートメソッドを区別する手段がない。 — すべてが公開されているのだ。そのため、クラスの利用者によって実際に使われることを想定していないメソッドは、パブリックAPIに置かないようにしよう。こうすることで意図せずメソッドが呼び出されてしまう可能性を減らすことができる。これには親クラスから上書きされたメソッドも含まれる。内部実装であるメソッドについては、パブリックヘッダに追加せずに実装ファイルに定義したカテゴリを使うこと。

Objective-C 2.0以前では、プライベート @interface でメソッドを宣言しておきながらメインの @implementation でメソッドを実装し忘れていても、コンパイラは何も警告してくれない。（個別のカテゴリの中でプライベートメソッドを実装していないためだ。） これを解決するには、カテゴリを指定した @implementation に関数を置けばよい。

もしObjective-C 2.0を使っているなら、代わりに クラスエクステンションを使ってプライベートカテゴリを宣言するべきだ。例えば次のようになる。

こうすると、宣言されたメソッドが @implementation セクションに実装されていることが保証される。もし実装されていなければコンパイラが警告を出してくれるためだ。

もう一度言っておこう。「プライベート」メソッドは実際にはプライベートではない。スーパークラスの「プライベート」メソッドをうっかり上書きしてしまうおそれもある。これはつぶすのが非常に難しいバグになる。一般的に、プライベートメソッドはかなり独特な名前にしておくべきだ。こうしておくと、意図せずサブクラスで上書きしてしまうのを避けることができる。

結局のところ、Objective-Cのカテゴリはすばらしい方法だ。これを使うと大きな @implementation セクションを、理解しやすいブロックに分割することができ、適切なクラスにアプリケーション特有の新機能を追加することができる。例えば、アプリにあるオブジェクトに行き当たりばったりに「両端一致」コードを追加するのではなく、NSString に新しいカテゴリを追加するようにしよう。

#import と #include のどちらを使うかは、インクルードしているヘッダの言語に基づいて選ぼう。

• Objective-CまたはObjective-C++を使っているヘッダをインクルードするときには、#import を使う。
• 標準のCまたはC++ヘッダをインクルードするときには、#include を使う。ヘッダには #define ガード を入れておくべきだ。

Objective-Cヘッダには #define ガードがなく、#import でインクルードされることしか想定していないものもある。Objective-Cソースファイルおよび他のObjective-CヘッダにインクルードされるのがObjective-Cヘッダだけのときには、全面的に #import を使うのが望ましい。

Objective-Cを含まない標準のCおよびC++ヘッダは、通常のCおよびC++ファイルにインクルードされることを想定している。標準のCやC++には #import がないので、#include によりインクルードされることになるだろう。Objective-Cソースファイルのなかで #include を使うということは、常に同じ意味でこれらのヘッダがインクルードされるということだ。

このルールはクロスプラットフォームのプロジェクトにおいて、うっかり間違ってしまうのを防ぐのに役立つ。新しいCやC++ヘッダを取り込んでいるMac開発者は、#define ガードを入れておくのを忘れてしまうことがある。この新しいヘッダを #import を使ってインクルードしていると、Macでは問題にならないだろう。しかし、#include を使う他のプラットフォームでは、ビルドに失敗するだろう。すべてのプラットフォームで #include を使うことで一貫性を持たせると、どのプラットフォームでもコンパイルは成功するか失敗するかのどちらかになり、特定のプラットフォームでしか動かないファイルがあるというのを避けることができる。

CocoaやFoundationといったフレームワークにあるシステムヘッダを個別にインクルードしたくなるかもしれないが、実際のところ、最上位のルートフレームワークをインクルードしてもコンパイラにとってはほとんど負荷にはならない。ルートフレームワークは通常プリコンパイルされており、非常にすばやくロードできるようになっているためだ。また、Objective-Cフレームワークには、#include ではなく #import を使うのを忘れないようにしよう。

ほんの少し遅くなるが、うっかり release を消してしまったり release の前に return を入れてしまって、メモリリークが発生するのを防くことができる。

新しいオブジェクトを変数に代入するときには、メモリリークを起こさないように最初に古いオブジェクトを解放する必要がある。これには「正しい」やり方がいくつかある。私たちは「autorelease してから retain する」という方法を選んだ。間違いにくいためだ。タイトなループでは、autorelease pool がいっぱいになり、効率が少し悪くなることに注意しよう。それでも私たちはこのトレードオフは許容できると考えた。

文字列を retain するだけでは不十分だ。文字列をコピーすれば、呼び出し元が知らないうちに文字列を変更してしまうことを避けることができる。実際には NSMutableString ではなく NSString を受け取っているから大丈夫だ、と考えてはいけない。

私たちは -fobjc-exceptions を付けてコンパイルするが、これは主に @synchronized を使うためだ。@throw は使わない。 @try、@catch、@finally の使用は、サードパーティ製のコードやライブラリを正しく使うのに必要であれば許される。もし例外を使うのであれば、どのメソッドが例外を投げる可能性があるのか正確に記載しておこう。

もしMacOS 10.2以前で動かす必要のないコードを書いているのなら、NS_DURING、NS_HANDLER、NS_ENDHANDLER、NS_VALUERETURN、NS_VOIDRETURN といったマクロを使ってはいけない。

また、Objective-C++のコードを書いているときには、Objective-Cの例外を投げるとスタックベースのオブジェクトは解放されないということを認識しておこう。例:

出力は次のようになる:

オブジェクト a のデストラクタは呼び出されないことに注意しよう。これは shared_ptr や linked_ptr のようなスタックベースのスマートポインタや、利用したいかもしれないSTLオブジェクトにとって大きな懸念事項になる。言いにくいことだが、Objective-C++のコードで例外を使わなければならないのなら、いつであれC++の例外を使おう。決してObjective-Cの例外を再び投げるべきではないし、スタックベースのC++オブジェクト（std::string や std::vector など）を、@try、@catch、@finally といったブロック本体で使うことも許されない。

nil チェックはクラッシュ防止のためではなく、アプリケーションのロジックフローのためだけに使うこと。nil オブジェクトへのメッセージ送信は、Objective-Cランタイムによって処理される。もしそのメッセージに戻すべき結果がなければ、何ごともなく進むことになる。結果があっても、ランタイムアーキテクチャ、リターンサイズ、OS Xのバージョンによって動作に違いがあるかもしれない。（詳しくはAppleのドキュメントを参照すること）

これはC/C++ポインタを NULL チェックするのとはまったく異なることに注意すること。C/C++ポインタでは NULL チェックをしないとランタイムはNULLを処理できず、アプリケーションはクラッシュしてしまう。常に NULL ポインタをデリファレンスしないようにする必要がある。

BOOL 型の定数である YES と NO を使うのは、戻り値と代入だけにすること。よくある間違いは配列のサイズをキャストしたり、ポインタ値を BOOL 型として扱ってしまうことだ。この結果は最後のバイトの値に依存して、常に NO になってしまうことがある。

BOOL 型を、C++およびその bool 型と同時に使用するときにも注意すること。単純に、YES が true に、NO が false に対応すると考えてはいけない。三項演算子を使うと、簡潔に対応づけることができる。

最後に、BOOL 型の変数を YES と直接比較してはいけない。Cに慣れた人にとって読みにくくなるだけでなく、最初に指摘したように戻り値が期待したものになるとは限らない。

Delegateパターンを実装するクラスは次のようにしておくべきだ。

1. delegateを参照する delegate_ という名前のインスタンス変数を用意する。
2. そして、アクセサメソッドは deletate と setDelegate: という名前にする。
3. delegate_ オブジェクトを retain するべきではない。

• モデルをビューから分離する: モデルやデータソースではプレゼンテーションについて何かを仮定してはいけない。データソースとプレゼンテーションとの間のインタフェースは抽象化しておくこと。ビューに関するモデル知識を与えてはいけない。（データソースのインスタンスを1つ考え、さまざまな状態を持つプレゼンテーションが複数可能かどうか、と考えるのはよい経験則だ。）
• コントローラをビューとモデルから分離する: 「ビジネスロジック」をすべて、ビュー関連のクラスに入れてはいけない。こうしてしまうと、そのコードはほとんど他に使い道がなくなってしまうだろう。こうしたコードはコントローラクラスに入れること。ただし、コントローラクラスではプレゼンテーションについてあまり多くを仮定しないこと。
• すべてのメソッドを実装する必要のあるコールバックAPIには、protocol を使うこと。必ずしもすべてのメソッドを実装する必要がないときには category（あるいは「非形式プロトコル」）を使うこと。