ストーリーボードセグエ識別子の命名規則
私は大きなストーリーボードを作成していますが、誰かが役立つセグエ識別子の命名規則=セグエ識別子の命名規則を考えているのではないかと思っていました。
Appleは、例の中で「ShowX」を使用しているだけです。Xは表示しているビューの名前です。これまでのところ、「PushX」または「ModalX」を使用して、トランジションのタイプです。他にトリックやヒントがありますか？
この質問に対する正解はありません。好み次第です。読みやすくするために軽減します。セグエ識別子に長い名前を付けることをためらわないでください。 Objective-Cは、非常に読みやすいコードを書くために私たちを利用する非常に冗長な言語であるため、長くて表現力豊かな名前を付けてください。
公式大会を探しましたが見つかりませんでした。 Appleのコメントは次のとおりです。
Interface Builderでセグエに識別子を割り当てます。識別子は、アプリケーションがセグエを区別するために使用する文字列です。たとえば、2つ以上の異なる宛先ビューコントローラーにセグエできるソースビューコントローラーがある場合、各セグエに異なる識別子を割り当てて、ソースビューコントローラーのprepareForSegue：sender：メソッドがそれらを区別し、各セグエを適切に準備できるようにします。 。
セグエに一意の識別子を与えます。 （ソースシーン内で一意である必要があります。異なるシーンで同じ識別子を使用できます。）
識別子名を選ぶための興味深いアプローチ（詳細は上記のリンクを参照）：
インターフェイスビルダーで名前を設定する前に、まずセグエ識別子名を確認するコードを記述します。私はこのコードについて話している：
if ([segue.identifier isEqualToString:@"SegueIdentifierName"])ビルドして実行！まだInterface Builderで識別子名を入力しないでください。 1つのView Controllerから複数の発信セグエがあり、それらを区別できるようにする必要があるためです。作業しているセグエを実行してトリガーしている間に何も起こらない場合、セグエ名識別子は一意であり、使用するのに適しています。代わりに、コードが意図していないセグエを実行する場合、サグ名識別子の競合があります。
競合を修正します-存在する場合。
Interface Builderでセグエ識別子を入力し、それが期待どおりに機能することをテストします。
TDDのアプローチに似ているので、これが好きです。失敗したテストを記述し、失敗したテストに合格するためのコードを記述し、リファクタリングし、繰り返します。
プログラミングのほとんどの場合と同様に、好きな名前を使用できます。
ただし、プログラミングのほとんどの場合と同様に、 names重要 および 良い名前は難しい です。
これが私がセグエスに名前を付ける方法です…
良いセグエ名
アクションメソッドに名前を付けるのと同じように名前を設定します。名前は、彼らが何をするかでセグエを選ぶ。良いセグエ名の例：
addUsershowReporteditAccountcomposeMessagereviewChanges
悪いセグエ名
Avoidセグエの名前は、セグドの対象とは何か、またはそれがどのように機能するかを説明するだけです。
悪いセグエ名の例!!：
- 悪い名前1！ –
segueUserDetailViewController–これを避けてください！ - 悪い名前2！ –
segueImageViewController–これを避けてください！ - 悪い名前3！ –
RecipeViewControllerToIngredientViewController–これを避けてください！
これらの名前が悪いのはなぜですか？
これらの名前は、実装を明示的に示しているため、不適切です。 彼らがすることという名前の代わりに、彼らは-彼らがそれをする方法と命名します。これは coupling の形式です。
したがって、あなたがしていることが「買い物かごの表示」である場合、これがたまたまZZBasketViewControllerを提示することによって行われるという事実は、呼び出し元にはまったく関係がなく、彼らが気にしない詳細で彼らに負担をかけるだけです。おそらく明日は、ZZShoppingItemsViewControllerまたはSTSuperConfigurableStuffListを使用して行われます。
そう：
showShoppingなどの名前を使用.- Avoid
showBasketViewControllerなどの名前を避けます。
すべてのプログラミングの命名規則
通常、抽象化のポイントは、抽象化がどのように機能するかをユーザーが知らない、または知らないことです。彼らが知っているのは、それが彼らのために何をするか、それが彼らにとって何を意味するかということです。
any抽象化の名前をneedlesslyに指定することは好ましくありません。callerがcalleeを規定するため、 =機能する必要があります。
このカップリングは：
- 必要のない知識で発信者に負担をかけます。
- 呼び出し先の実装を不必要に制約します。
- メンテナンスまたは将来の削除を必要とする無意味で費用のかかる方法で、発信者を着信者に結び付けます。
その後誰かがignoresカップリングして実装を変更した場合、指定された名前が嘘をつき始め、将来のプログラマを誤解させる名前も変更されない限り、誰がコードを見るか。
セグエは抽象化です。セグエ名は実装を参照しないでください。
Cocoaの識別子規約に従う
SwiftとObjective Cはどちらも識別子に camelCase を使用しています。
- 名前に
_または-文字を含めることはできません。 - タイプ、クラス、プロトコルを除き、すべての名前の最初の文字は小文字にする必要があります。
camelCaseでセグエに名前を付け、小文字の最初の文字を付けます。
一意性は必要ありません
セグエ名は不可は、ストーリーボード内で一意である必要があります。名前は、特定のシーン（ビューコントローラー）内でのみ一意である必要があります。
Ileaの回答 はRayのサイトから引用してこれについて言及しています：
ソースシーン内で一意でなければなりません。異なるシーンで同じ識別子を使用できます。
…実際、多くのシーンからaddLocationを作成できる場合があるため、ストーリーボードの多くのシーンで同じセグエ名を使用することは、多くの場合意味があります。
セグエの命名と使用に関するその他のヒント…
same他のシーンに行くセグエが1つ以上あるシーン
これは私が少し使用するものです。アカウント情報を表示および編集できるビューコントローラーがある場合があります：AccountVC。これに行くシーンから2つ以上のセグエを持つことを止めるものは何もありませんsame他のビューコントローラーのシーン：editAccountとshowAccount。 prepareForSegue:sender:は、セグエIDを使用してAccountVCを適切に設定し、編集または表示することができます。
senderを使用します
セグエは送信者で呼び出されるため、アクションメッセージに非常によく似ています。
セグエのsenderを使用して、prepareForSegue:sender:実装で宛先ビューコントローラを構成します。これにより、ビューコントローラーを一時的な状態で汚染する手間が省けます。
タップを処理するテーブルビューデリゲートの例を次に示します。
- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
Account *const account = [self accountAtIndexPath: indexPath];
[self performSegueWithIdentifier: showAccount sender: account];
}
これにより、prepare…メソッドは次のようになります。
- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender
{
if([showAccount isEqualToString: segue.identifier])
{
AccountViewController *accountVC = segue.destinationViewController;
accountVC.account = sender;
}
}
@"stringLiterals"呼び出しでperformSegue:を回避する
「これはshowAccountとは何ですか？@"showAccount"を意味しますよね？」と質問した場合。重要なヒントは次のとおりです。セグエ名にファイルスコープ変数を使用します。 @"string literals"。は使用しないでください。したがって、私のビューコントローラの上部には、次のようなブロックがよくあります。
DEFINE_KEY(showReport);
DEFINE_KEY(showPDF);
DEFINE_KEY(shareReport);
マクロDEFINE_KEYは私のプロジェクトの.pchにあり、次のようになります。
#define DEFINE_KEY(keyName) static NSString *const keyName = @#keyName
…const NSString*変数を作成します。その値はその名前と同じです。 staticは、この「コンパイルユニット」でのみ使用でき、リンク時にグローバル名前空間を汚染しないことを意味します。
このような変数を使用する場合、コンパイラはあなたの側にあります。ビルドされないため、名前を間違えることはありません。コード補完は、開始する名前を完成させるのに役立ちます。他の変数と同じように名前をリファクタリングできます。構文ハイライターもあなたの側にあります！
リラックスしたセグエを例外のように考える
デスティネーションのビューコントローラは、アンワインドセグエの例外ハンドラであると考えてください。アンワインドセグエは、例外がコールスタックを伝播するように、ナビゲーションスタックを伝播します。セグエは、例外が例外ハンドラー（catchブロック）を探すように、巻き戻しハンドラーを探します。アンワインドセグエのタイプに適したアンワインドハンドラーを探しています。これも、検索される例外のタイプの例外ハンドラーのようなものです。
重要なのは、同じアンワインドハンドラーを実装する多くのビューコントローラーを使用できることです。巻き戻しは、それを処理する最初のView Controllerの例外のようにバブルアップします。
アンワインドネーミングに関する通常のアドバイスは、unwindToMessageListのようなものです。これは理にかなっていますが、「例外ハンドラ」というメタファーに従って、アンワインドハンドラの名前を処理することで非常に役立ちます。したがって、unwindFromEventDetails、unwindFromReport、またはunwindFromCloseupImageは、何がキャッチされているかを表す適切な名前になる可能性があります。これらのハンドラーは、複数の可能なキャッチサイトで実装できます。ナビゲーション階層を使用して、適切なハンドラーが自動的に選択されます。
"ViewControllerAToViewControllerB"
たとえば、MasterViewControllerとDetailViewControllerがある場合、セグエ識別子は次のようになります。
"MasterToDetail"
個人的には、アニメーションタイプを前に使用しません。アニメーションを変更した場合は、コードに戻る必要があります。ただし、ソースコントローラーでセグエ識別子を定数として宣言すると、コードを掘り下げることなく、後の段階でより簡単に名前を変更できます。
私は通常、「ViewController」なしで、コントローラに付けた名前を使用します。したがって、RatingViewControllerはストーリーボードとして「Rating」になります。 1つの例外は、アンワインドセグエです。 "returnTo"で始まり、宛先の名前で終わる名前を付けます（ "returnToRating"）。