很好。这里的典型例子是

public Background {
    public Color Color { get; set; }
}

这里出现了一些罕见的问题（极端情况），但还不足以保证避免使用这个设备。坦率地说，我觉得这个设备相当有用。我不会喜欢不能做到以下几点：

class Ticker { ... }

public StockQuote {
    public Ticker Ticker { get; set; }
}

我不想说Ticker StockTicker或Ticker ThisTicker等。

Microsoft Naming Guideline for Members状态：

考虑为属性指定与其类型相同的名称。

当您具有枚举的强类型属性时，该属性的名称可以与枚举的名称相同。例如，如果您具有名为CacheLevel的枚举，则返回其值之一的属性也可以命名为CacheLevel。
虽然我承认有一点模糊，他们是否只是建议这对枚举或属性一般。

我只能想到一个缺点。如果你想做这样的事情：

public class B1
{
        public static void MyFunc(){ ; }
}

public class B2
{
        private B1 b1;

        public B1 B1
        {
                get { return b1; }
                set { b1 = value; }
        }

        public void Foo(){
                B1.MyFunc();
        }
}

您必须改为用途：

MyNamespace.B1.MyFunc();

这方面的一个很好的常见用法示例是在Winforms编程中，其中System.Windows.Forms.Cursor类与System.Windows.Forms.Forms.Cursor属性重叠，因此窗体事件必须使用完整的命名空间访问静态成员。

就在今天，埃里克在博客上发表了关于“颜色”问题的文章。
https://learn.microsoft.com/en-us/archive/blogs/ericlippert/color-color
就我个人而言，如果可能的话，我会避免。

另一个陷阱是内部类型。
我经常碰到这种情况：

public class Car {
    public enum Make {
        Chevy,
        Ford
    };

    // No good, need to pull Make out of the class or create
    // a name that isn't exactly what you want
    public Make Make {
        get; set;
    }
}

这没有什么特别的技术问题。它可能会损害或提高可读性。事实上，一些微软库有这类属性（特别是enum属性，这通常是有意义的）。

这种常见模式是我在引用类中的示例成员时总是使用this的原因之一。

this.SomeMethod(this.SomeProperty);

而且从来没有

SomeMethod(SomeProperty);

在大多数情况下，没有任何实际的歧义，但我发现它有助于澄清事情。另外，您现在知道属性/方法是在哪里定义的。

当属性的名称和它的类型相同时，这显然会有点混乱，但除此之外，这并不是一个真正的问题。
如果名称有意义，通常最好让名称和类型相同，如果你能想到一个更好的名称，你当然应该使用它，但你不应该为了避免这种情况而不惜任何代价编造一个名称。

除了大小写不同之外，我给予事物的名称与它们的类型相同：我的方法和属性都是小写的因此我就不会有MiffTheFox的问题。

public class B1
{
    public static void myFunc(){ ; }
}

public class B2
{
    private B1 m_b1;

    public B1 b1
    {
        get { return m_b1; }
        set { m_b1 = value; }
    }

    public void Foo()
    {
        B1.myFunc(); //this is Ok, no need to use namespace
    }
}

因此，对于我来说，m_b1是成员数据，b1是属性（或者局部变量或参数），B1是类名。