タイプを命名するための良いテクニックやテストはありますか？

厄介な、未解決の質問ですが、それは私がいつも反対している問題です：

保守と操作が簡単なソフトウェアは、適切に設計されたソフトウェアです。設計を直観的にしようとすると、次の開発者がコンポーネントの機能を推測できるような方法でコンポーネントに名前を付けます。これが、クラスに「Type1」、「Type2」などの名前を付けない理由です。

実際の概念（顧客など）をモデル化する場合、これは一般に、モデル化される実際の概念に基づいて型に名前を付けるのと同じくらい簡単です。しかし、よりシステム指向の抽象的なものを構築する場合、読みやすく、簡単に消化できる名前を使い果たすことは非常に簡単です。

（私にとっては）コンポーネントの動作を説明する基本型またはインターフェイスを使用して、型のファミリに名前を付けようとすると悪化します。これは当然、派生型ごとに実装のフレーバー（IDataConnectionおよびSqlConnection.NET Frameworkなど）を記述しようとしますが、「リフレクションによる動作と特定の属性セットの検索」のような複雑なものをどのように表現しますか？

次に、やろうとしていることを説明していると思われるタイプの名前を最終的に選択したら、同僚は「WTFはDomainSecurityMetadataProvider実際にこれを行うのですか？」と尋ねます。

コンポーネントの意味のある名前を選択するための良いテクニックはありますか、または混乱した名前を取得せずにコンポーネントのファミリーを構築する方法はありますか？

名前に適用できる簡単なテストはありますか？

命名については、私にとって有効であることが証明された6つの手法があります。

1. 名前の発明に多くの時間を費やす
2. コードレビューを使用する
3. 改名することをheしないでください
4. 名前の発明に多くの時間を費やす
5. コードレビューを使用する
6. 改名することをheしないでください

PS。APIが公開される場合、その前に上記が適用されます。

「ダイヤモンドのような公開APIは永遠に存在します。それを正しく実現するチャンスがあるので、最善を尽くしてください...」（Joshua Bloch、優れたAPIを設計する方法と重要な理由）

私の基本的なテストは、変数の単語のみを使用して変数の機能を説明できるかどうかです。

たとえば、DomainSecurityMetadataProviderが「ドメインセキュリティメタデータを提供する」または「ドメインセキュリティに関連するメタデータを提供する」場合、それは良いことです。

ただし、人によって異なるニュアンスがあります。

たとえば、私にとって、original_team_codeは元のチームのコードですが、他の人にとっては元のチームのコードかもしれません。私が個人的に気に入っているのは「UnsafeLegacyMutex」で、「これはThreadUnsafe Legacy Codeのミューテックス」ではなく、「これは安全ではないレガシーミューテックスです」と読むしかありませんでした。

したがって、私の拡張テストでは、変数をボード/ wiki /チャットに書き留め、それが何を意味するかを人々に推測させます。

コンポーネントの意味のある名前を選択するための良いテクニックはありますか、または混乱した名前を取得せずにコンポーネントのファミリーを構築する方法はありますか？

あんまり。

ただし、1つのヒントは「受動的な声」を避けることです。

「DomainSecurityMetadataProvider」はパッシブです。動詞はなく、すべて名詞と形容詞として使用される名詞です。

「ProvideMetadataForDomainSecurity」はよりアクティブです。動詞があります。

オブジェクト指向プログラミングはすべて（本当に）名詞の動詞です。名詞==オブジェクト。動詞==メソッド。したがって、クラス名は一般的に非常に「名詞」です。この習慣を破り、動詞の挿入を開始することは困難です。

名前に適用できる簡単なテストはありますか？

はい。質問で優れたテストを定義しました。他の人に聞いてください。

昔は、これを「デザインウォークスルー」と呼んでいました。ウォーターフォールの方法論では、汗をかくような大きな取引でした。最近では、アジャイルメソッドを使用すると、クラスの作成者とユーザー間の通常のコラボレーションが必要になります。時間がかかりません（そうすべきではありません）。テスト（およびコード）を記述する前に設計（および名前）について議論することで、驚asの要因を減らし、WTFを防ぐことができます。

シソーラスを使用する

クラスやメソッドを説明する適切な単語を見つけるために、新しい開発を行うときにシソーラスを参照することが非常に多いです。

主に操作ロジックを含むクラス

「EntityProvider」、「EntityLocator」など、主に名詞動詞構造で操作メソッドを提供するクラスに名前を付ける傾向があります。

通常、これらのクラスには多くの状態が含まれていません。

状態を含むクラス

UI画面とデータエンティティは一般にステートフルです。したがって、これらのクラスに名詞または形容詞と名詞のパターンを付けて単純に名前を付けます。

例：Person、Employee、CurrentEmployee、FormerEmployee

ユーティリティクラス

静的メソッドのみを含むクラスは、通常「ユーティリティ」クラスと見なされるため、一貫して「ユーティリティ」サフィックスを付けて名前を付けています。

例：NetworkUtilities、FileUtilities

テスト

何かが不十分な名前であるかどうかを判断するための良いテストはありませんが、名前に単一の名詞および/または単一の動詞を使用して、その名詞/動詞があなたが何を正確に説明しているかを考えることをお勧めします名前を付け直します。

名前でキャプチャされていないクラス/メソッドに他にもあると感じる場合、そのクラス/メソッドをリファクタリングする必要があるかもしれません。

アラン・グリーンとジェフ・アトウッドは、「Manager」という接尾辞を付けたクラスの命名の悪さについて書いています。彼らは、「マネージャー」という用語は使い過ぎであり、意味のあるものを伝えるには曖昧すぎると主張しています。同意しなければなりません。

Jeffの記事には、Steve McConnellのCode Completeから推奨されるガイドラインのリストも記載されています。

変数

最近、「Of」、「By」、「For」などの前置詞を組み込んだ、より長い説明的な変数/パラメーター名を試しています。いくつかの例を以下に示します。

string firstNameOfEmployee;

string lastNameOfEmployee;

// here I nimbly avoid worrying about whether to call it "Id" or "ID" :)
int idOfEmployee;

decimal amountForDeposit;

Account accountForDeposit;

これはVisual Studioのインテリセンス機能でうまく機能し、これらの長い名前を簡単に入力できることがわかりました。また、変数名プレフィックスの重複が少ないこともわかります（たとえば、personID、personFirstName、personLastName対idOfPerson、firstNameOfPerson、lastNameOfPerson）。インテリセンスをさらに便利にする、より良い「ハッシュ」を提供します。

次に、やろうとしていることを説明していると思うタイプの名前を最終的に選択したら、同僚は「このDomainSecurityMetadataProviderは実際にWTFを実行しますか？」と尋ねます。

複雑でドメイン固有のクラスにはどのような名前を期待しますか？これは、クラス名を文にせずに得られるものとほぼ同じです（単一のクラスにあまりにも多くの責任を与えたと誰もが思うようになります）

名前からプロバイダーを削除することを検討します。特にメタデータに言及している場合、誰もがあなたがリフレクションを使用していることをすでに知っています。あなたはそれを1つの単語をより簡潔にすることができます（またはおそらく別の単語に変更します-それはあなたが書いたものからのプロバイダよりも消費者です）

メタファーを使用して、システムの一部を説明します。それは新しい類推を発見するだけでなく、命名を容易にするのに役立ちます。

（これは強力な例ではありませんが、とにかく）たとえばmailbox、クラスの受信メッセージのキューとして機能する変数またはタイプを呼び出すことができます。

私は非常にしっかりだろう一つは名前がなければならないということです決して正しくないと認められません。最良の例は、いくつかのリファクタリング中に、多くのコードが変更され、いくつかの変数が名前が示唆したもの以外のものを参照し始めたことです。

すぐに、あるプログラマーは年齢をかけて、すでに抽出され保存された特定のデータを取得しようとして、非常に高価なデータベース呼び出しを使用していました。私はすべての名前を変更しましたが、突然、膨大な複雑でバグの多いロジックを削除できました。

うまくいけば、名前について一生懸命に考えなければならないケースはまれです。それらのケースが発生したら、クラスが何をするのかを説明するパラグラフを書いてください。関数内のコメントや関数レベルのコメントとは異なり、クラスの主な目的はめったに変更されないため、コメントが古くなるリスクは比較的小さくなります。したがって、クラスの機能を説明するために、いくつかの段落を書いたり、ASCIIを描画したりする余裕があります。