财产是否应该与其types相同？
我有时看到这样的代码：
public class B1 { } public class B2 { private B1 b1; public B1 B1 { get { return b1; } set { b1 = value; } } } 即，类B2具有名为“B1”的属性，其也是types“B1”。
我的直觉告诉我，这不是一个好主意，但是有没有什么技术上的原因，为什么你应该避免给一个属性同名？
（我使用.net 2.0，以防万一）。
没关系。 这里的典型例子是
public Background { public Color Color { get; set; } }
有一些罕见的问题（angular落案例）出现在这里，但不足以保证避免这个设备。 坦率地说，我觉得这个设备相当有用。 我不喜欢不能做到以下几点：
class Ticker { ... } public StockQuote { public Ticker Ticker { get; set; } }
我不想说， Ticker StockTicker或Ticker ThisTicker等
微软针对会员的命名指南指出：
考虑赋予一个属性与其types相同的名称。
当你有一个强types为枚举的属性时，属性的名称可以和枚举的名字相同。 例如，如果您有一个名为
CacheLevel的枚举，则返回其值之一的属性也可以命名为CacheLevel。
虽然我承认，他们是不是只是推荐这个Enums或者一般的属性，有点含糊不清。
就在今天，埃里克博客了关于“颜色颜色”的问题。
http://blogs.msdn.com/ericlippert/archive/2009/07/06/color-color.aspx
就我个人而言，如果可能的话，我会避免它。
我只能想到一个缺点。 如果你想做这样的事情：
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.Form.Cursor属性重叠，因此表单事件必须使用完整名称空间来访问静态成员。
没有具体的技术问题。 这可能会损害或提高可读性。 事实上，一些微软库有这些属性（具体来说，与enum属性，这通常是有道理的）。
另一个问题是内部types。
我一直遇到这个：
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; } }
当一个属性的名称和types相同时，显然可能会有点混乱，但除此之外，这不是一个真正的问题。
如果名称有意义，通常最好让名称和types相同。 如果你能想到一个更好的名字，你当然应该使用这个名字，但是你不应该为了避免这种情况而不惜一切代价地冒名。
这种常见模式是我在引用一个类中的实例成员时总是使用this的原因之一。 例如总是
this.SomeMethod(this.SomeProperty);
永不
SomeMethod(SomeProperty);
在大多数情况下，没有任何实际的歧义，但我觉得这有助于澄清事情。 另外你现在知道属性/方法的定义。
除了大小写之外，我给它们的名称与它们的types相同。我的方法和属性是“lowerCase”; 所以我不会有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是属性（或局部variables或参数）， B1是类的名称。
