C# 属性是否应该与其类型具有相同的名称？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1095644/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Should a property have the same name as its type?
提问by Moe Sisko
I've sometimes seen code written like this :
我有时会看到这样写的代码：
public class B1
{
}
public class B2
{
private B1 b1;
public B1 B1
{
get { return b1; }
set { b1 = value; }
}
}
i.e. class B2 has a property named "B1", which is also of type "B1".
即类 B2 有一个名为“B1”的属性，它也是“B1”类型。
My gut instinct tells me this is not a good idea, but are there any technical reasons why you should avoid giving a property the same name as its class ?
我的直觉告诉我这不是一个好主意，但是有什么技术上的原因你应该避免给一个属性与它的类同名吗？
(I'm using .net 2.0, in case that matters).
（我正在使用 .net 2.0，以防万一）。
采纳答案by jason
It's fine. The canonical example here is
没关系。这里的规范示例是
public Background {
public Color Color { get; set; }
}
There are rare issues (corner cases) that come up here, but not enough to warrant avoiding this device. Frankly, I find this device quite useful. I would not enjoy not being able to do the following:
这里出现了罕见的问题（角落案例），但不足以保证避免使用此设备。坦率地说，我发现这个设备非常有用。我不会喜欢不能做以下事情：
class Ticker { ... }
public StockQuote {
public Ticker Ticker { get; set; }
}
I don't want to have to say Ticker StockTickeror Ticker ThisTickeretc.
我不想说Ticker StockTicker或Ticker ThisTicker等等。
回答by SolutionYogi
Just today, Eric blogged about the 'Color Color' problem.
就在今天，Eric 发表了关于“颜色颜色”问题的博客。
http://blogs.msdn.com/ericlippert/archive/2009/07/06/color-color.aspx
http://blogs.msdn.com/ericlippert/archive/2009/07/06/color-color.aspx
Personally, I would avoid it if possible.
就我个人而言，如果可能的话，我会避免它。
回答by Mehrdad Afshari
There's no specific technical problem with it. It might harm or improve readability. In fact, some Microsoft libraries have these kind of properties (specifically, with enumproperties, this usually makes sense).
它没有特定的技术问题。它可能会损害或提高可读性。事实上，一些 Microsoft 库具有这些类型的属性（特别是对于enum属性，这通常是有意义的）。
回答by MiffTheFox
I can only think of one drawback. If you wanted to do something like this:
我只能想到一个缺点。如果你想做这样的事情：
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();
}
}
You'd have to instead use:
你必须改为使用：
MyNamespace.B1.MyFunc();
A good example of this is common usage is in Winforms programming, where the System.Windows.Forms.Cursor class overlaps with the System.Windows.Forms.Form.Cursor property, so your form events have to access static members using the full namespace.
一个很好的例子是在 Winforms 编程中的常见用法，其中 System.Windows.Forms.Cursor 类与 System.Windows.Forms.Form.Cursor 属性重叠，因此您的表单事件必须使用完整的命名空间访问静态成员.
回答by Guffa
It can obviously be a bit confusing when the name of a property and it's type are the same, but other than that it's not really a problem.
当一个属性的名称和它的类型相同时，这显然有点令人困惑，但除此之外，这并不是一个真正的问题。
If the name makes sense, it's usually better to let the name and the type be the same. If you can think of a better name, you should of course use that, but you should not try to make up a name at any cost just to avoid this situation.
如果名称有意义，通常最好让名称和类型相同。如果你能想到一个更好的名字，你当然应该使用它，但你不应该为了避免这种情况而不惜一切代价去编一个名字。
回答by ChrisW
I give things the same name as their type, except for case: my methods and properties are "lowerCase"; and I therefore wouldn't have the problem that MiffTheFox has.
我给事物命名与其类型相同的名称，但大小写除外：我的方法和属性是“小写”；因此我不会有 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
}
}
So for me, m_b1is member data, b1is a property (or a local variable or parameter), and B1is the name of the class.
所以对我来说，m_b1是成员数据，b1是属性（或局部变量或参数），B1是类的名称。
回答by Chris
Another gotcha is with inner types.
另一个问题是内部类型。
I run into this one all the time:
我一直遇到这个：
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;
}
}
回答by Annabelle
This common pattern is one of the reasons why I always use thiswhen referring to an instance member within a class. e.g. always
这种常见模式是我this在引用类中的实例成员时总是使用的原因之一。例如总是
this.SomeMethod(this.SomeProperty);
and never
绝不
SomeMethod(SomeProperty);
In most cases, there isn't any actual ambiguity, but I find it helps clarify things. Plus you now know where the property/method is defined.
在大多数情况下，没有任何实际的歧义，但我发现它有助于澄清事情。另外，您现在知道属性/方法的定义位置。
回答by Dan Diplo
The Microsoft Naming Guideline for Membersstate:
在微软的命名指南会员状态：
Consider giving a property the same name as its type.
When you have a property that is strongly typed to an enumeration, the name of the property can be the same as the name of the enumeration. For example, if you have an enumeration named
CacheLevel, a property that returns one of its values can also be namedCacheLevel.
考虑为属性指定与其类型相同的名称。
当您有一个强类型化为枚举的属性时，该属性的名称可以与枚举的名称相同。例如，如果您有一个名为 的枚举
CacheLevel，则返回其值之一的属性也可以命名为CacheLevel。
Though I admit there is a little ambiguity whether they are just recommending this for Enums or for properties in general.
尽管我承认他们是否只是为枚举或一般属性推荐这个有点含糊不清。
