これはGoogle Objective-C Style Guide (2.24)の日本語訳です。
オリジナルと同様、CC-By 3.0 Licenseで配布します。
最終更新: 2011-05-08

Revision 2.24

Mike Pinkerton
Greg Miller
Dave MacLachlan
（日本語訳 Takashi Sasai）
このスタイルガイドには詳細情報がたくさん盛り込まれていますが、最初のうちは表示されていません。左端にある矢印ボタンをクリックしてみてください。 「やったね」と表示されるはずです。

やったね！ このように矢印ボタンをクリックすると詳細情報が表示されます。 このドキュメントの先頭にある大きな矢印ボタンをクリックしても構いません。すると、すべての詳細情報が表示されます。

Objective-Cとは、C言語に対して非常に動的なオブジェクト指向拡張を追加したプログラミング言語です。この言語は使いやすくて読みやすいように設計されており、複雑なオブジェクト指向設計がこなせます。またObjective-Cは、Mac OS XおよびiPhone上で動く新しいアプリケーションを開発するための主要な開発言語となっています。

Cocoaとは、Mac OS Xにおける主要なアプリケーションフレームワークのひとつです。これはObjective-Cクラスの集合により構成されています。Cocoaを使うことで、機能に富んだMac OS Xアプリケーションをすばやく開発できます。

AppleはすでにObjective-Cコーディングガイドを公開しています。これは非常によくできていて、開発者に広く受け入れられています。Googleもまた、C++コーディングガイドを公開しています。このObjective-Cガイドが目標にしているのは、AppleとGoogleが一般的に推奨していることを、できる限りそのまま組み合わせることにあります。そのため、このガイドを読む前に、以下のドキュメントを読んでおくことが望ましいです。

たとえ本ドキュメントに明記されていなくても、GoogleのC++スタイルガイドで禁止されていることは、Objective-C++でもすべて禁止されていることに注意してください。

本ドキュメントの目的は、あらゆるMac OS Xコードで使われるべき、Objective-C（およびObjective-C++）のコーディングガイドラインとプラクティスについて説明することです。このガイドラインの大部分は、さまざまなプロジェクトやさまざまなチームで何年もかけて作り上げられたもので、有効性が実証されています。 Googleが開発しているオープンソースプロジェクトは、このスタイルガイドに準拠しています。

Googleはすでに、 Google Toolbox for Mac project （本ドキュメントでは省略して、GTMと呼びます）の一部として、このガイドラインに準拠したオープンソースコードをリリースしています。他のプロジェクトと共有する予定のあるコードは、このリポジトリに入れておくとよいでしょう。

このガイドはObjective-Cのチュートリアルではないことに注意してください。読者はあらかじめObjective-Cについてよく知っていることを想定しています。Objective-Cを使うのが初めての人や、もう少し勉強する必要があると感じている人は、まず The Objective-C Programming Language を読んでください。

百聞は一見にしかず、ということわざがあります。まずは例を見てみましょう。スタイル、空白、命名規則などが実際にどんな感じか、雰囲気がつかめるはずです。

ヘッダファイルの一例。@interface 宣言のためのコメントと空白がどんな感じかわかるでしょう。

// GTMFoo.h // FooProject // // Created by Greg Miller on 6/13/08. // Copyright 2008 Google, Inc. All rights reserved. // #import <Foundation/Foundation.h> // A sample class demonstrating good Objective-C style. All interfaces, // categories, and protocols (read: all top-level declarations in a header) // MUST be commented. Comments must also be adjacent to the object they're // documenting. // // (no blank line between this comment and the interface) @interface GTMFoo : NSObject { @private NSString *foo_; NSString *bar_; } // Returns an autoreleased instance of GMFoo. See -initWithString: for details // about the argument. + (id)fooWithString:(NSString *)string; // Designated initializer. |string| will be copied and assigned to |foo_|. - (id)initWithString:(NSString *)string; // Gets and sets the string for |foo_|. - (NSString *)foo; - (void)setFoo:(NSString *)newFoo; // Does some work on |blah| and returns YES if the work was completed // successfuly, and NO otherwise. - (BOOL)doWorkWithString:(NSString *)blah; @end

ソースファイルの一例。インタフェースの @implementation のためのコメントと空白がどんな感じかわかるでしょう。このファイルには、ゲッタやセッタ、init や dealloc といった主要なメソッドのリファレンス実装も含まれています。

// // GTMFoo.m // FooProject // // Created by Greg Miller on 6/13/08. // Copyright 2008 Google, Inc. All rights reserved. // #import "GTMFoo.h" @implementation GTMFoo + (id)fooWithString:(NSString *)string { return [[[self alloc] initWithString:string] autorelease]; } // Must always override super's designated initializer. - (id)init { return [self initWithString:nil]; } - (id)initWithString:(NSString *)string { if ((self = [super init])) { foo_ = [string copy]; bar_ = [[NSString alloc] initWithFormat:@"hi %d", 3]; } return self; } - (void)dealloc { [foo_ release]; [bar_ release]; [super dealloc]; } - (NSString *)foo { return foo_; } - (void)setFoo:(NSString *)newFoo { [foo_ autorelease]; foo_ = [newFoo copy]; } - (BOOL)doWorkWithString:(NSString *)blah { // ... return NO; } @end

@interface、@implementation、@end の前後の空行は、あってもなくても構いません。もし @interface がインスタンス変数を宣言しているなら、たいていの場合、閉じ中括弧（}）の後に空行を入れるべきです。

わずかなプライベートメソッドやブリッジクラスを宣言するときなど、インタフェースや実装がごく短い場合を除いて、通常は空行を入れるようにしましょう。読みやすくなります。

スペースだけを使いましょう。インデントはスペース2つにします。

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

コードにおけるテキスト1行の長さは、長くても80文字にするべきです。

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

このルールには賛否両論あると思いますが、既存のコードの大部分がすでにこれを守っています。そして、私たちは一貫性が重要だと考えています。

Xcode の場合、Xcode > 環境設定 > テキスト編集 > ページガイドを表示 を設定しておけば、ルールに違反している箇所を簡単に見つけられます。

- や + と戻り値との間には、スペースを1つ入れるべきです。パラメータリストには、パラメータ間のスペースを除いて、スペースを入れるべきではありません。

メソッドは次のようにするべきです。

- (void)doSomethingWithString:(NSString *)theString { ... }

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

パラメータが多すぎて1行に収まりきらないときには、1行につきパラメータを1つ書いてください。パラメータが複数行にわたるときには、パラメータの前にあるコロンで整列させましょう。

- (void)doSomethingWith:(GTMFoo *)theFoo rect:(NSRect)theRect interval:(float)theInterval { ... }

最初のキーワードが他のキーワードよりも短いときには、以降の行を少なくともスペース4つでインデントしてください。コロンで整列させるのではなく、キーワードの先頭で整列させても構いません。

- (void)short:(GTMFoo *)theFoo longKeyword:(NSRect)theRect evenLongerKeyword:(float)theInterval { ... } メソッド呼び出しはメソッド宣言と同じ書式にするべきです。 書式を選ぶときには、そのソースですでに使われている規約にしたがいましょう。

呼び出しでは、次のようにすべての引数を1行に入れるか、

[myObject doFooWith:arg1 name:arg2 error:arg3];

次のように1行につき引数を1つ書いて、コロンで整列させるべきです。

[myObject doFooWith:arg1 name:arg2 error:arg3];

次のような書式にしてはいけません。

[myObject doFooWith:arg1 name:arg2 // 引数を複数含む行がある error:arg3]; [myObject doFooWith:arg1 name:arg2 error:arg3]; [myObject doFooWith:arg1 name:arg2 // コロンではなくキーワードで整列させている error:arg3];

メソッド宣言やメソッド定義と同様に、キーワードが長いために、コロンで整列させると、先頭にスペース4つ分を空けられない場合があります。そのときには、コロンで整列させる代わりに、以降の行をスペース4つでインデントしてキーワードで整列させてください。

[myObj short:arg1 longKeyword:arg2 evenLongerKeyword:arg3]; @public および @private アクセス修飾子は、スペース1つでインデントするべきです。

これはC++における public、private、protected のルールと同じです。

@interface MyClass : NSObject { @public ... @private ... } @end 例外の書式は、@ ラベルと開き括弧（{）の間にスペースを1つ入れて、1行につき@ ラベル1つにしてください。また、@catch とキャッチされるオブジェクトの宣言との間にも、同じようにスペースを1つ入れてください。

どうしてもObjective-Cの例外を使う必要があるなら、次のような書式にしてください。ただし、「例外をスローするのを避ける」を読んで、なぜ例外を使うべきでないか確認してください。

@try { foo(); } @catch (NSException *ex) { bar(ex); } @finally { baz(); } タイプ識別子とかぎ括弧に包まれたプロトコル名の間にはスペースを入れるべきではありません。

これはクラス宣言、インスタンス変数、メソッド宣言に適用します。

@interface MyProtocoledClass : NSObject<NSWindowDelegate> { @private id<MyFancyDelegate> delegate_; } - (void)setDelegate:(id<MyFancyDelegate>)aDelegate; @end

コードをメンテナンス可能にするためには、命名規則が極めて重要になります。Objective-Cのメソッド名は非常に長くなりがちですが、コードがまるで文章のように読めるという利点があります。そのおかげで、それほどコメントを入れる必要はないはずです。

純粋なObjective-Cのコードを書くときには、標準であるObjective-C naming rulesにほぼ準拠します。しかし、このAppleの命名ガイドラインは、GoogleのC++スタイルガイドで説明したものとは大きく異なっています。例えば、Google C++スタイルガイドでは、変数名には単語と単語の間にアンダースコア（_）を入れたものを使うよう推奨していますが、Appleのガイドラインでは、インターキャプス（intercaps）を使うよう推奨しています。Objective-Cの世界では、これが標準のやり方になっています。

クラス、カテゴリ、メソッド、変数の名前には、すべて大文字のイニシャリズム（頭字語）を使っても構いません。URL、TIFF、EXIFなど、すべて大文字の頭字語を使うAppleの標準にしたがっています。

ところが、Objective-C++のコードを書くときには、そう単純な話ではありません。Objective-CやCocoaとともに、クロスプラットフォーム用のC++ APIを実装したり、C++バックエンドとネイティブCocoaフロントエンド間のブリッジを実装したりする必要のあるプロジェクトもたくさんあります。このような場合には、これら2つのガイドラインが直接ぶつかってしまいます。

私たちがとった解決策は、実装しようとしているメソッド/関数のガイドラインにしたがう、というものです。@implementation ブロックの中なら、Objective-Cの命名規則を使いましょう。C++の class に含まれるメソッドを実装しているなら、C++の命名規則を使いましょう。こうすることで、ひとつの関数の中でインスタンス変数とローカル変数の命名規則が混在することはなくなります。異なる命名規則が混在すると、極めて読みにくいコードになってしまいます。

ファイル名は、そのファイルに含まれるクラス実装の名前を反映したものにするべきです。これには大文字と小文字の違いも含みます。プロジェクトで使っている規約にしたがいましょう。

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

.h C/C++/Objective-Cのヘッダファイル
.m Objective-Cの実装ファイル
.mm Objective-C++の実装ファイル
.cc 純粋なC++の実装ファイル
.c Cの実装ファイル

カテゴリのためのファイルの名前には、拡張されるクラス名が含まれるべきです。例えば、GTMNSString+Utils.h や GTMNSTextView+Autocomplete.h とします。

Objective-C++のソースファイルでは、実装しようとしている関数/メソッドのスタイルに準拠してください。

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

// file: cross_platform_header.h class CrossPlatformAPI { public: ... int DoSomethingPlatformSpecific(); // プラットフォームごとの実装 private: int an_instance_var_; }; // file: mac_implementation.mm #include "cross_platform_header.h" // Objective-Cの命名規則を使った、典型的なObjective-Cクラス @interface MyDelegate : NSObject { @private int instanceVar_; CrossPlatformAPI* backEndObject_; } - (void)respondToSomething:(id)something; @end @implementation MyDelegate - (void)respondToSomething:(id)something { // CocoaからC++バックエンドへのブリッジ instanceVar_ = backEndObject->DoSomethingPlatformSpecific(); NSString* tempString = [NSString stringWithInt:instanceVar_]; NSLog(@"%@", tempString); } @end // C++の命名規則を使った、C++クラスによるプラットフォーム固有の実装 int CrossPlatformAPI::DoSomethingPlatformSpecific() { NSString* temp_string = [NSString stringWithInt:an_instance_var_]; NSLog(@"%@", temp_string); return [temp_string intValue]; } クラス名（カテゴリ名やプロトコル名も同様）は、大文字で始めて、大文字と小文字を組み合わせて単語を区切った書式にするべきです。

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

カテゴリ名は、あるプロジェクトの一部であること、あるいは汎用でオープンであることがわかるよう、2文字もしくは3文字のプレフィックスで始めるべきです。カテゴリ名には、そのカテゴリが拡張しているクラス名を盛り込むべきです。

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

クラス名とカテゴリの開き括弧の間にはスペースを1つ入れるべきです。

メソッド名は小文字で始めて、それ以降は大文字と小文字を組み合わせたものにするべきです。名前付きパラメータも同じように、小文字で始めるべきです。

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

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

このルールはObjective-Cのメソッドにだけ適用されます。C++のメソッド名や関数名はC++スタイルガイドにあるルールにしたがいます。

変数名は小文字で始めて、大文字と小文字を組み合わせて単語を区切った書式にしてください。クラスメンバ変数はアンダースコア（_）で終わってください。例えば、myLocalVariable や myInstanceVariable_ とします。もしObjective-C 2.0の @property が使えない場合には、KVO/KVCバインディング用のメンバをアンダースコアで始めても構いません。

スタティック型（intやポインタ）のような変数の構文上の属性に、ハンガリアン記法を使ってはいけません。無理のない範囲で、できるだけわかりやすい名前にしてください。水平方向のスペースをけちってはいけません。新しくコードを読む人がすぐに理解できるようにすることの方が、はるかに重要なことです。

int w; int nerr; int nCompConns; tix = [[NSMutableArray alloc] init]; obj = [someObject object]; p = [network port]; int numErrors; int numCompletedConnections; tickets = [[NSMutableArray alloc] init]; userInfo = [someObject object]; port = [network port];

インスタンス変数は大文字と小文字を組み合わせて、アンダースコアで終わるようにするべきです。例えば、usernameTextField_ とします。しかし、KVO/KVCとObjective-C 2.0を使ったメンバ変数へのバインディングが使えないとき（OSによる制限のため）は例外です。この場合には、変数のプレフィックスとしてアンダースコアを付けても構いません。Appleは慣習として、key/valueの命名にこれを許しています。もしObjective-C 2.0が使えるのであれば、@property と @synthesize を使って、この命名ガイドラインにしたがってください。

定数名（#define、enum、constなローカル変数など）は小文字 k で始めて、大文字と小文字を組合せて単語を区切ります。例えば、kInvalidHandle や kWritePerm とします。

コメントを書くのは苦痛ですが、コードを読みやすくするには不可欠です。以下に、どこにどんなコメントを書いておくべきか説明します。 でも忘れないでください: コメントは非常に重要ですが、最高のコードとは自己文書化されたコードのことです。あいまいな名前を付けてコメントで説明しようとするよりも、型や変数に理にかなった名前を付けておく方がはるかによいことです。

コメントを書くときには、コードを読む人のために書いてください。つまりコードを理解する必要のある次のコントリビュータ（貢献してくれる人）のためです。親切心をもちましょう — 次のコントリビュータというのはあなた自身かもしれませんよ！

C++スタイルガイドで取り上げたルールや規約は、このガイドラインでもすべて有効だということを忘れないでください。ここでは追加したポイントについて取り上げています。

各ファイルはまずコピーライト宣言から始めて、その後にファイルの説明を続けてください。

すべてのファイルには、以下の項目を以下の順序で入れるべきです。

  • コピーライトに関する文 （例えば、 Copyright 2008 Google Inc. など）
  • ライセンスの決まり文句。そのプロジェクトで使うライセンスに合わせて決まり文句を選びます。（例えば、 Apache 2.0, BSD, LGPL, GPL など）

もともと他人が書いたファイルに大きな変更をしたときには、作者のところに自分の名前を追加してください。これは、他のコントリビュータがそのファイルについて質問したり、問い合わせ先を知りたいときに非常に役に立ちます。

インタフェース、カテゴリ、プロトコルの宣言にはすべて、目的と全体における位置付けを説明するためのコメントを入れておくべきです。 // アプリケーションの起動終了の通知を処理する、NSApplication の Delegate。 // メインのアプリコントローラによって所有される。 @interface MyAppDelegate : NSObject { ... } @end

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

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

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

コメント中に変数名やシンボルを引用するときには、引用符やシンボルをインラインで指定するのではなく、垂直バー（縦棒）を使ってください。

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

// Sometimes we need |count| to be less than zero.

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

// Remember to call |StringWithoutSpaces("foo bar baz")| 一般的なObjective-Cから外れた使い方をしているときには、オーナーシップモデルをできる限り明確に示してください。

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 されていない （例: デリゲート）

 メンバ変数は @private と宣言しておくべきです。 @interface MyClass : NSObject { @private id myInstanceVariable_; } // public accessors, setter takes ownership - (id)myInstanceVariable; - (void)setMyInstanceVariable:(id)theVar; @end 指定イニシャライザがわかるよう、コメントを入れてください。

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

init... メソッドを必要とするサブクラスを書くときには、スーパークラスの指定イニシャライザを上書きしていることを確認してください。

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

オーバーライドした NSObject のメソッドは @implementation の一番上に置くのが典型的なプラクティスであり、そうすることを強く推奨します。 これは init...、copyWithZone:、deallocといったメソッドによく適用されます（これらに限りませんが）。 init... メソッド群をひとまとめにして、その後に copyWithZone: メソッドが、最後に dealloc メソッドが続くようにするべきです。 init メソッド内で変数を 0 や nil で初期化してはいけません。これは冗長です。

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

NSObject のクラスメソッドである new を呼び出してはいけません。サブクラスで new をオーバーライドしてもいけません。保持されたオブジェクトをインスタンス化するためには、alloc と init メソッドを使ってください。

最近のObjective-Cコードは、オブジェクトを保持するために、明示的に alloc と init メソッドを呼び出します。new クラスメソッドはめったに使われないので、 これを使うと正しいメモリ管理ができているかコードをレビューするのが難しくなります。

クラスをシンプルにしておきましょう。「キッチンシンク」（いろいろなものを積め込んだような）APIにしてはいけません。メソッドをパブリックにする必要がなければ、パブリックにしてはいけません。プライベートカテゴリを使って、ヘッダがぐちゃぐちゃになるのを防ぎましょう。

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

// GTMFoo.m #import "GTMFoo.h" @interface GTMFoo (PrivateDelegateHandling) - (NSString *)doSomethingWithDelegate; // プライベートメソッドの宣言 @end @implementation GTMFoo(PrivateDelegateHandling) ... - (NSString *)doSomethingWithDelegate { // このメソッドの実装 } ... @end

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

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

@interface GMFoo () { ... }

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

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

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

Objective-C/Objective-C++ヘッダには #import を、C/C++ヘッダには #include を使ってください。

#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 を使うということは、これらのヘッダは常に同じセマンティックスでインクルードされることになります。

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

#import <Cocoa/Cocoa.h> #include <CoreFoundation/CoreFoundation.h> #import "GTMFoo.h" #include "base/basictypes.h" 個別のファイルではなくルートフレームワークをインクルードしてください。

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

#import <Foundation/Foundation.h> // よい #import <Foundation/NSArray.h> // 避けよう #import <Foundation/NSString.h> ... 一時的なオブジェクトを新しく生成するときには、そのメソッドの終わりの方で個別に release するのではなく、オブジェクトの生成と同じ行で autorelease しましょう。

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

// 避けよう（やむを得ないパフォーマンス上の理由がない限り） MyController* controller = [[MyController alloc] init]; // ... リターンするかもしれないコード ... [controller release]; // 望ましい MyController* controller = [[[MyController alloc] init] autorelease]; オブジェクトの代入には、autorelease してから retain する、というパターンを使いましょう。

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

- (void)setFoo:(GMFoo *)aFoo { [foo_ autorelease]; // |foo_| == |aFoo| であれば、deallocしない foo_ = [aFoo retain]; } @interface に宣言したのと同じ順序で、インスタンス変数を dealloc するべきです。こうしておけば、レビューアが確認しやすくなります。

新規もしくは変更された dealloc の実装をチェックするため、コードレビューアは保持されたインスタンス変数がすべて解放されたか確認しなくてはなりません。

dealloc をレビューしやすくするため、@interface に宣言したのと同じ順序で保持されたインスタンス変数を解放してください。dealloc が他のメソッドを呼び出してインスタンス変数を解放している場合には、そのメソッドでどのインスタンス変数が解放されているのか、コメントに書いておきましょう。

NSString を引数に持つセッタは、受け取った文字列を必ず copy するべきです。

文字列を retain するだけでは十分ではありません。文字列をコピーしておけば、知らないうちに呼び出し元が文字列を変更してしまうといった事態が避けられます。NSMutableString ではなく NSString を受け取っているから大丈夫だと考えてはいけません。

- (void)setFoo:(NSString *)aFoo { [foo_ autorelease]; foo_ = [aFoo copy]; } Objective-Cの例外を @throw してはいけません。ただしサードパーティ製のコードやOS呼び出しからの例外は、キャッチできるようしておくべきです。

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

Mac OS X 10.2以前で動かす必要のあるコードを書いていない限り、NS_DURING、NS_HANDLER、NS_ENDHANDLER、NS_VALUERETURN、NS_VOIDRETURN といったマクロを使ってはいけません。

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

class exceptiontest { public: exceptiontest() { NSLog(@"Created"); } ~exceptiontest() { NSLog(@"Destroyed"); } }; void foo() { exceptiontest a; NSException *exception = [NSException exceptionWithName:@"foo" reason:@"bar" userInfo:nil]; @throw exception; } int main(int argc, char *argv[]) { GMAutoreleasePool pool; @try { foo(); } @catch(NSException *ex) { NSLog(@"exception raised"); } return 0; }

出力は次のようになります。

2006-09-28 12:34:29.244 exceptiontest[23661] Created 2006-09-28 12:34:29.244 exceptiontest[23661] exception raised

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

nil チェックはロジックフローのためだけに使ってください。

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

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

通常の整数値を BOOL 型に変換するときには注意してください。YES と直接比較してはいけません。

Objective-Cでは、BOOL 型は unsigned charとして定義されています。つまり、YES (1) と NO (0) 以外の値を取り得るということです。通常の整数値を直接 BOOL 型にキャストしたり、変換しようとしてはいけません。よくある間違いとして、配列のサイズやポインタ値、BOOL に対するビット論理の結果をキャストしてしまうことがあります。これらは、整数値の最後のバイト値によって、常に NO になるおそれがあります。通常の整数値を BOOL に変換するときには、YES か NO の値を返す三項オペレータを使ってください。

BOOL、_Bool、bool は、安全に置き換え、変換が可能です（ C++標準 4.7.4、4.12 および C99標準 6.3.1.2を参照）。BOOL と Boolean は安全に置き換えられないため、先ほど説明したように Boolean を通常の整数値として扱ってください。Objective Cのメソッドシグニチャには、BOOL だけを使ってください。

BOOL とともに、論理オペレータ（&&、||、!）を使うこともできます。これを使うと、三項オペレータを使わなくても、安全に BOOL に変換された値を返せます。

- (BOOL)isBold { return [self fontTraits] & NSFontBoldTrait; } - (BOOL)isValid { return [self stringValue]; } - (BOOL)isBold { return ([self fontTraits] & NSFontBoldTrait) ? YES : NO; } - (BOOL)isValid { return [self stringValue] != nil; } - (BOOL)isEnabled { return [self isValid] && [self isBold]; }

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

BOOL great = [foo isGreat]; if (great == YES) // ... great! BOOL great = [foo isGreat]; if (great) // ... great! 一般的にプロパティを使うときには以下のことに注意してください。プロパティはObjective-C 2.0の機能であり、プロパティを使ったコードはiPhoneやMac OS X 10.5（Leopard）以上でしか動きません。ドット記法が使えるのは、宣言された @property にアクセスするときだけです。

プロパティに対応するインスタンス変数名は、アンダースコア（_）で終わらなければなりません。プロパティ名は、対応するインスタンス変数名から最後のアンダースコア（_）を取り除いたものにするべきです。@property と開き括弧の間のスペースは、例にあるように省略するべきです。

@synthesize ディレクティブを使ってプロパティの名前を変更してください。

@interface MyClass : NSObject { @private NSString *name_; } @property(copy, nonatomic) NSString *name; @end @implementation MyClass @synthesize name = name_; @end

プロパティ宣言はクラスインタフェースのインスタンス変数ブロックの直後に置くべきです。プロパティ定義はクラス定義の @implementation ブロックの直後に置くべきです。これらは、まわりにある @interface や @implementation と同じレベルにインデントしてください。

@interface MyClass : NSObject { @private NSString *name_; } @property(copy, nonatomic) NSString *name; @end @implementation MyClass @synthesize name = name_; - (id)init { ... } @end

NSStringプロパティには、必ず copy 属性を宣言するべきです。

これは、NSStringのセッタには必ず retain の代わりに copy を使わなければならない、というルールに論理的にしたがったものです。

CFType には必ず @dynamic 実装ディレクティブを付けるべきです。

CFType は retain プロパティ属性を持てないため、開発者が自分でその値をretainしたりreleaseしなければなりません。まれに代入したいときもありますが、その場合には、実際にセッタやゲッタを実装して、その理由をコメントに明記しておくのが望ましいです。

デフォルトの @dynamic であったとしても、すべてのプロパティに実装ディレクティブを付けてください。

たとえ @dynamic がデフォルトだとしても、クラスのプロパティがそれぞれどのように処理されるのか一目でわかるよう、プロパティの実装ディレクティブはすべて明示的に列挙してください。

@interface MyClass : NSObject @property(readonly) NSString *name; @end @implementation MyClass . . . - (NSString*)name { return @"foo"; } @end @interface MyClass : NSObject @property(readonly) NSString *name; @end @implementation MyClass @dynamic name; . . . - (NSString*)name { return @"foo"; } @end

プロパティにはオーバーヘッドがあることを認識しておいてください。デフォルトでは、同期のセッタとゲッタはすべてアトミックになります。そのため、セットとゲットの呼び出しには同期オーバーヘッドがかなりあります。アトミック性が必要ないなら、プロパティを nonatomic と宣言しておいてください。

ドット記法はObjective-C 2.0の慣用スタイルです。オブジェクトの @property をget/setするために単純な操作をするときには使っても構いませんが、他のオブジェクトの挙動を呼び出すために使うべきではありません。

NSString *oldName = myObject.name; myObject.name = @"Alice"; NSArray *array = [[NSArray arrayWithObject:@"hello"] retain]; NSUInteger numberOfItems = array.count; // プロパティではない array.release; // プロパティではない Delegateオブジェクトをretainするべきではありません。

Delegateパターンを実装するクラスは、次のようにするべきです。

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

モデルをビューから分離しましょう。コントローラをビューとモデルから分離しましょう。コールバックAPIには @protocol を使ってください。

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

Revision 2.24

Mike Pinkerton
Greg Miller
Dave MacLachlan
（日本語訳 Takashi Sasai）