在C#中,在类中引用成员属性的普遍接受的方式是什么?

我认为,无论您使用何种命名约定,最重要的是保持一致性。 我个人使用下划线前缀约定。(其中一个原因是我使用NHibernate,而NHibernate有一个“field.camelcase下划线”访问策略。

关于你的另一个问题: 这取决于你想做什么。
您的属性是否包含额外的逻辑?您是否希望在引用它时执行此逻辑?然后使用属性。你不想执行逻辑?使用该字段。 埃里克·利珀特写了一篇文章 post 关于这一点在他的博客上。

首先,对于简单的get/set情况,我建议您使用自动实现的属性。如果这样做,编译器将生成基础变量,而您只引用属性本身。

我使用样式Cop,它在代码上强制执行一些样式。我发现这非常有用,我的所有团队成员也使用它。

虽然关于样式Cop的使用有很多讨论,但我建议的一件事是,如果您使用样式Cop,那就是保持所有样式都处于启用状态。这样,当您在用户之间共享时,事情会变得容易得多。

其中一个信息是您不能用下划线命名您的私有字段。因此,我通常在编写私有字段时使用camelCase,然后在编写公共属性时使用PascalCase:

private string name;
public string Name
{
    get { return this.name; }
    set { this.name = value; }
}

this. 这使事情更容易阅读。

如果不能像Brian Rasmussen建议的那样使用自动实现的属性,并且必须有一个私有成员,那么我建议使用下划线前缀_name。

在intellisense中,一个项是参数、本地成员还是私有成员并不明显,因为它们都有相同的符号(蓝色立方体)。但是,如果将光标移动到某个特定项目,则工具提示会告诉您该项目是哪一个。

我过去非常反对使用前缀“u”,但它在intellisense中非常有用,当您想要快速访问成员字段而不必键入许多字母时。

一方面我同意你应该使用公司标准,另一方面我会努力遵守行业标准。

我会重复前面的回答,即您应该坚持您的团队使用的方案,或者如果您不在团队中,则应与您使用的任何方案保持一致。

就我个人而言,我使用下划线前缀,因为我发现它给了我一个很好的视觉提示。

我认为普遍接受的命名约定仅仅是为了使名称有意义(并且代码简洁明了)。在我看来,如果代码中的标识符出于任何原因需要视觉提示,那么它太复杂了,而且名称通常不完全准确。

只要确保丹尼斯·格林(前亚利桑那州红衣主教教练)的这句话适用于你的识别码:“他们就是我们想象中的那个人!”

这样做的一个原因是,如果您稍后向setter添加逻辑,您很可能希望它在任何地方都能使用。

对于类级变量,我们的编码标准是使用mVariableName或m_VariableName。最重要的是要遵循你的公司/老师/等编码标准/实践。

一、 从个人角度来说,只有通过getter/setter访问变量(如果有)。即使变量只在类内部使用,我也使用自动属性。通过这种方式,我添加了一层操作,这意味着如果我修改了一些东西,重构的代码会更少。

顺便说一句,您的void函数不能返回字符串…:-)

我只想补充一点,MSDN命名指南没有规定这一点,因为它只有公共接口的指南(即属性名称、公共方法、公共方法参数等)。它们不关心私有成员样式,因此,就Microsoft而言,您可以使用您和您的团队想要的任何东西。

首先,我和我共事过的许多其他人已经废除了在私人成员前面加“m_”的做法。接下来,每当我在类中引用private成员时,我通常在“this.privateMemberVariableName”中使用this这个词。使用此选项足以区分变量不是局部变量或作为方法内的参数传递的变量。

如果公共属性名包含的逻辑不仅仅是引用私有成员变量,例如实例化连接或在视图状态中保存属性值,那么我会引用公共属性名。

framework Design guidelines book 说你不应该在变量前面加上u-你应该用小写字母作为变量的名称,我相信CodeComplete2Edition说你不应该在变量前面加上m_u。