C＃の宣言型と同じ名前をプロパティ/メンバーに付けるのは悪い習慣ですか？

たとえば、次のようなクラス：

class Dog { } //never mind that there's nothing in it...

そして、次のようなプロパティ：

Dog Dog { get; set; }

もっと想像力に富んだ名前が思いつかない場合は、次を使用する必要があると言われました。

Dog DogObject { get; set; }

これらの名前をより良くする方法についての考えはありますか？

コンテキストに基づいてコードで何を話しているかがすでに明らかであるという事実がなければ、それは悪い習慣かもしれません。

Dog = new Dog();

型コンストラクタはどれですか？オブジェクトはどれですか？混乱していない？OK

Dog = Dog.Create()?

オブジェクトはどれですか？型の静的ファクトリメソッドはどれですか？まだ混乱していない？そうは思いませんでした。

私がこれが潜在的な問題であるとわかったのは、名前空間ツリーがかなり精巧になり、コンパイラがあいまいさを理解できないときだけです。その場合、次のような結果になります

Dog = new Some.Namespace.Dog();

いずれにせよ、ローカル変数名は常にキャメルケースされ、あいまいさを完全に回避するため、これは自動プロパティ（およびおそらく列挙）でのみ発生します。

dog = new Dog();

これは合理的な慣行であるだけでなく、言語はこれを許可するように特別に設計されました。ルールと正当性については、C＃仕様の「Color Color」を検索し、参照してください。

http://blogs.msdn.com/b/ericlippert/archive/2009/07/06/color-color.aspx

この決定から生じるいくつかの興味深いコーナーケースのために。

プロパティをそのタイプと同じように呼び出さないようにするために、どのような状況でもプロパティに「DogObject」という名前を付けてはなりません。これは、フレームワークの設計ガイドラインと直接矛盾しています。

これを呼び出すことは完全に問題ありません。Dog実際、これはMicrosoftがフレームワークの命名ガイドラインで推奨しているものです。

プロパティにそのタイプと同じ名前を付けることを検討してください。

たとえば、次のプロパティはColorという名前の列挙値を正しく取得および設定するため、プロパティの名前はColorになります。

そして、上記のガイドで使用する例は次のとおりです。

public enum Color {...}
public class Control {
    public Color Color { get {...} set {...} }
}