たとえば、次のようなクラス:
class Dog { } //never mind that there's nothing in it...
そして、次のようなプロパティ:
Dog Dog { get; set; }
もっと想像力に富んだ名前が思いつかない場合は、以下を使用する必要があると言われています。
Dog DogObject { get; set; }
これらをよりよく命名する方法についての考えはありますか?
コンテキストに基づいて、コードで何を話しているのかがすでにかなり明白であるという事実がなければ、それは悪い習慣になる可能性があります。
Dog = new Dog();
型コンストラクタはどれですか?オブジェクトはどれですか?混乱していませんか?はい、どうですか
Dog = Dog.Create()?
オブジェクトはどれですか?タイプの静的ファクトリーメソッドはどれですか?まだ混乱していませんか?そうは思いませんでした。
これが潜在的な問題であると私が見たのは、名前空間ツリーがかなり複雑になり、コンパイラーがあいまいさを理解できないときだけです。
Dog = new Some.Namespace.Dog();
いずれにせよ、ローカル変数名は常にcamelCasedであり、あいまいさを完全に回避しているため、これは自動プロパティ(およびおそらく列挙型)でのみ発生します。
dog = new Dog();
これは合理的な慣行であるだけでなく、この言語を許可するように特別に設計されました。ルールと理由については、C#仕様の「Color Color」を検索して、
http://blogs.msdn.com/b/ericlippert/archive/2009/07/06/color-color.aspx
この決定から生じるいくつかの興味深いコーナーケースについて。
どのような状況でも、プロパティと同じタイプを呼び出さないようにするために、プロパティに「DogObject」という名前を付けてはなりません。これは、フレームワークの設計ガイドラインと直接矛盾します。
これをDog
と呼ぶのはまったく問題ありませんが、これは実際、Microsoftが フレームワークの命名ガイドライン で推奨しているものです。
プロパティにそのタイプと同じ名前を与えるCONSIDER。
たとえば、次のプロパティはColorという列挙値を正しく取得および設定するため、プロパティの名前はColorになります。
上記のガイドで使用する例を次に示します。
public enum Color {...}
public class Control {
public Color Color { get {...} set {...} }
}