将属性/成员命名为与C＃中的声明类型相同的做法不好吗？

25

例如，一个类似的类：

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

然后是类似的属性：

Dog Dog { get; set; }

有人告诉我，如果我不能为它想出一个更富想象力的名称，那么我必须使用：

Dog DogObject { get; set; }

对如何更好地命名这些有任何想法吗？

c# naming properties

— 风暴基尔南
source

2

您已经被告知的这一要求似乎是脑筋急转弯，可能是由于过度执行了良好的指导方针（有更好的名称时不要只是使用类型名称）。

2

由于成员名称不能与封闭类型相同，因此它甚至无法在C＃中编译。

— 李

3

@李：我认为上下文是该属性是另一种类型。例如，一个Person包含Dog名为Dog

— goric

3

我的意思是，如果她确实是狗，请给她贴上这样的标签。

— Thomas Eding 2013年

1

IDE的语法突出显示应区分类型和属性。当您不使用IDE时，您始终可以查看上下文。

— Cyanfish

22

这不是一个好习惯，如果不是基于上下文，您正在谈论的代码已经很明显的事实的话。

Dog = new Dog();

哪个是类型构造函数？哪个对象？不困惑吗？好那怎么样

Dog = Dog.Create()?

哪个对象？类型上的静态工厂方法是什么？还是不困惑？我不这么认为。

我唯一一次看到这是一个潜在的问题是，当命名空间树变得相当复杂时，编译器无法弄清歧义，在这种情况下，您会得到类似

Dog = new Some.Namespace.Dog();

在任何情况下，这仅应在自动属性（可能是枚举）中发生，因为局部变量名称始终是驼峰式的，从而完全避免了歧义。

dog = new Dog();

— 罗伯特·哈维
source

7

+1。而且替代方案都更糟：“ TheDog”，“ AnyDog”，“ MyDog”等。当没有要添加的内容时，最好不要添加任何内容。

— 凯文·克莱恩

我想如果由于某种原因Dog使实例方法称为Create，第二个方法可能会造成混乱，但是那时候您将陷入一些非常糟糕的编码实践中。

— KDiTraglia 2013年

40

这不仅是一种合理的做法，而且还专门设计了该语言以允许这样做。在C＃规范中搜索“颜色”以获取规则和理由，然后查看

对于此决策产生的一些有趣的极端情况。

在任何情况下，都不应将属性命名为“ DogObject”，以避免与其属性类型相同。与框架设计准则直接矛盾。

— 埃里克·利珀特
source

如果属性类型是其实例没有身份的属性（例如Color），则这种用法似乎是合理的。我不太喜欢可变或IDisposable类型。“控件的Font”是指由属性封装的状态的那些方面，还是Font由属性getter标识的状态的实例？

— 2014年

7

称呼它很好Dog，这实际上是Microsoft在Framework命名指南中建议的：

考虑为属性赋予与类型相同的名称。

例如，以下属性正确获取并设置了一个名为Color的枚举值，因此该属性名为Color。

这是他们在上述指南中使用的示例：

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

— 伊萨克·萨沃（Isak Savo）
source