在 C + + 和 C # 变量中使用变数命名原则-下划线

在 class 字段中常常可以看到 _var变量名。下划线是什么意思？是否有所有这些特殊命名约定的参考？

213267 次浏览
小开

它仅仅意味着它是类中的一个成员字段。

小开

没有什么特别的变数命名原则但我见过私人会员。

小开

Microsoft 的 C # 命名标准说，变量和参数应该使用小骆驼大小写形式 IE: paramName。该标准还要求字段遵循相同的形式，但这可能导致代码不清晰，因此许多团队要求使用下划线前缀，以提高清晰度 IE: _fieldName。

小开
最佳答案

下划线只是一种约定，仅此而已。因此，它的使用总是有点不同的每个人。下面是我对这两种语言的理解:

在 C + + 中，下划线通常表示私有成员变量。

在 C # 中，我通常只在为公共属性定义底层私有成员变量时才使用它。其他私有成员变量不会有下划线。不过，随着自动属性的出现，这种用法在很大程度上已经过时了。

以前:

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

之后:

public string Name { get; set; }
小开

根据我的经验(当然是有限的) ，下划线将表明它是一个私有成员变量。正如咕噜所说，这将取决于团队。

小开

我对类的成员变量使用 _ var 命名，主要有两个原因:

1)它帮助我在以后阅读代码时跟踪类变量和局部函数变量。

2)当我在寻找类变量时，它在智能感知(或其他代码完成系统)中有所帮助。了解第一个字符有助于筛选可用变量和方法列表。

小开

许多人喜欢在私有字段前面加上下划线，这只是一个变数命名原则。

C # 的“官方”命名约定为私有字段规定了简单的小写名称(没有下划线)。

我不知道 C + + 的标准约定，尽管下划线被广泛使用。

小开

这样的变数命名原则在你阅读代码的时候很有用，尤其是不是你自己的代码。一个强大的变数命名原则有助于表明某个特定成员在哪里定义，它是什么类型的成员，等等。大多数开发团队都采用简单的变数命名原则，在成员字段前加一个下划线(_fieldName)。在过去，我使用过下面的 C # 变数命名原则(它是基于微软的。NET 框架代码，可以通过反射器看到) :

实例字段: m _ fieldName
静态字段: s _ fieldName
Public/Protected/Internal Member: PascalCasedName ()
私人会员: camelCasedName ()

这有助于人们在快速阅读不熟悉的代码时理解成员的结构、用法、可访问性和位置。

小开

这只是一些程序员在操作类的成员或其他类型的变量(参数、函数的局部变量等)时用来表达清楚的约定。另一个广泛用于成员变量的约定是在名称前面加上“ m _”。

无论如何，这些只是惯例，你不会找到一个单一的来源，为所有的。它们是一种风格，每个编程团队、项目或公司都有自己的(甚至没有)。

小开

对于 C # ，Microsoft框架设计指引建议不要为 公众人士成员使用下划线字符。对于 二等兵成员，可以使用下划线。实际上，杰弗里 · 里克特(指南中经常引用)使用 m _ for 实例和“ s _”表示私有静态成员。

就我个人而言，我只用 _ 来标记我的私人成员。“ m _”和“ s _”接近匈牙利命名法。NET，但是可能非常冗长，而且我发现有许多成员的类很难按字母顺序快速扫描(想象一下10个变量都以 m _ 开头)。

小开

实际上，_var约定来自 VB，而不是 C # 或 C + + (m _，... 是另一回事)。

这克服了 VB 在声明属性时对大小写不敏感的问题。

例如，这样的代码在 VB 是不可能的，因为它认为 user和 User是相同的标识符

Private user As String


Public Property User As String
Get
Return user
End Get
Set(ByVal Value As String)
user = value
End Set
End Property

因此，为了克服这个问题，有些人使用了一个约定将’_’添加到私有字段，如下所示

Private _user As String


Public Property User As String
Get
Return _user
End Get
Set(ByVal Value As String)
_user = value
End Set
End Property

因为很多会议都是为了。为了保持 C # et VB.NET 约定之间的一致性，他们使用了相同的约定。

我找到了我要说的话的参考: Http://10rem.net/articles/net-naming-conventions-and-programming-standards——-best-practices

带前导下划线的骆驼箱 VB.NET，始终表示“受保护”或 “私人”，不要使用“昏暗”。使用 不鼓励使用“ m _”，也不鼓励使用 变量名不同于 财产，尤其是与 保护变量，因为这违反了 遵守，并会使你的生活 痛苦，如果你在 VB.NET 编程，因为你 你们的会员名单 一些不同于 访问器/变异器属性 这里的项目，前导下划线 是唯一有争议的。 我个人比较喜欢直的 我的无下划线骆驼箱 私人变量，所以我没有 用“ this”限定变量名 区别于... 中的参数 或其他地方 可能会有命名冲突。 由于 VB.NET 对大小写不敏感，这个 更重要的是 访问器属性通常具有 和你的私人会员同名 除下划线外的变量。 至于 m _ 去，它真的是公正的 关于美学。我(和许多其他人) 发现我很丑，因为它看起来像在那里 是变量名中的一个空格。它是 几乎是无礼的，我以前用过 VB6的所有时间，但这只是 因为变量不能有 带头的下划线，我不可能是 很高兴看到它消失。微软 建议反对 m _ (和 即使他们两个都做了 在他们的代码中。另外，以一个 直接的“ M”就出来了，当然, 因为他们主要用 C # 编码，所以他们可以 只有不同的私人成员 以防从属性。 VB 乡亲 不得不做点别的，而不是 试着想出 按语言分列的特殊情况，我 为... 推荐前面的下划线 所有支持它的语言。如果 我希望我的课能充分 符合 CLS 标准，我可以省去 任何受 C # 保护的成员的前缀 然而，在实践中，我 永远不要担心这个，因为我保持所有 潜在受保护的成员变量 私有化，保护供应 为什么: 简而言之，这个会议是 简单(一个字符) ，易于阅读 (你的眼睛不会被别人分心 主角) ，并成功地 避免命名冲突 程序级变量和 类级别属性。

小开

您可以创建自己的编码指南，只需为团队的其他成员编写一份清晰的文档。

Using _ field 可以帮助 Intelilsense 过滤所有只需键入 _ 的类变量。

我通常遵循 布拉德 · 亚当斯指南，但它建议不要使用下划线。

小开

第一个评论者(R Samuel Klatchko)引用了: 在 C + + 标识符中使用下划线的规则是什么？，它回答了 C + + 中关于下划线的问题。通常，不应该使用前导下划线，因为它是为编译器的实现者保留的。您在 _var中看到的代码可能要么是遗留代码，要么是使用旧的命名系统编写的代码，这种命名系统并不反对使用前导下划线。

正如其他的应答状态一样，它曾经在 C + + 中用于标识类成员变量。然而，就修饰符或语法而言，它没有特殊的意义。因此，如果你想使用它，它将编译。

我将把 C # 讨论留给其他人。

小开

如果代码也必须可以从 VB.NET 扩展，那么在 C # 中使用它是完全合理的。 (否则，我不会这么做。)

因为 VB.NET 是不区分大小写的，所以没有简单的方法来访问这段代码中受保护的 field成员:

public class CSharpClass
{
protected int field;
public int Field { get { return field; } }
}

例如，这将访问属性获取器，而不是字段:

Public Class VBClass
Inherits CSharpClass


Function Test() As Integer
Return Field
End Function


End Class

见鬼，我甚至不能写小写字母 field-VS2010只是不断纠正它。

为了使它能够方便地被 VB.NET 中的派生类访问，我们必须想出另一个变数命名原则。在下划线前面加上前缀可能是最不具侵入性的，也是最“历史上被接受的”。

小开

就 C 和 C + + 语言而言，名称(开头、中间或结尾)中的下划线没有特殊含义。它只是一个有效的变量名字符。“约定”来自编码社区内的编码实践。

正如上面的各个例子所指出的，_ 在开头可能意味着 C + + 中类的私有或受保护成员。

让我来讲一些历史，也许会是有趣的琐事。在 UNIX 中，如果您有一个核心 C 库函数和一个内核后端，您希望将内核函数公开给用户空间，那么 _ 就会停留在直接调用内核函数的函数存根的前面，而不做任何其他操作。最著名和最熟悉的例子是 BSD 和 SysV 类型的内核下的 exit () vs _ exit () : 在那里，exit ()在调用内核的出口服务之前处理用户空间的事情，而 _ exit 只是映射到内核的出口服务。

在这种情况下，So _ 被用于“ local”，即 local 是 machine-local。通常 _ function ()是不可移植的。在这一点上，你不应该期望在不同的平台上有相同的行为。

现在是 for _ in 变量名，如

Int _ foo;

从心理学的角度来说，一开始就输入 an _ 是一件很奇怪的事情。因此，如果希望创建一个与其他变量冲突的可能性较小的变量名，尤其是在处理预处理器替换时，需要考虑使用 _。

我的基本建议是始终遵循编码社区的约定，这样您可以更有效地协作。

小开

现在，对于 C # 类成员变量来说，使用“ this”的表示法是可以接受的。它替换了旧的“ m _”或者仅仅是“ _ _”符号。它确实使代码更具可读性，因为毫无疑问引用的是什么。

小开

_ var 没有任何意义，只是为了更容易区分变量是私有成员变量。

在 C + + 中，使用 _ var 约定是不好的形式，因为在标识符前有规则控制下划线的使用。_ Var 保留为全局标识符，而 _ Var (下划线 + 大写字母)随时保留。这就是为什么在 C + + 中，你会看到人们使用 var _ 约定。

小开

在 C + + 中，最好不要在任何变量名或参数名之前使用 UNDERSCORES

以下划线或双下划线开头的名称为 C + + 实现者保留。带下划线的名称保留给库使用。

如果你读过 C + + 编码标准，你会在第一页看到:

不要过度规范命名，但是一定要使用一致的变数命名原则: a)永远不要使用“下划线名称”，不要使用以下划线开头或者包含双下划线的名称。(p2，c + + 编码标准，Herb Sutter 和 Andrei Alexandrescu)

更具体地说，ISO 工作草稿规定了实际的规则:

此外，一些标识符被保留给 C + + 实现使用，不得在其他情况下使用; 不需要进行诊断。(a)包含双下划线 _ _ 或以下划线开头、后跟大写字母的每个标识符都保留给实现以供使用。(b)以下划线开头的每个标识符都保留给实现，以便在全局命名空间中作为名称使用。

最好的做法是避免以下划线开始一个符号，以防您不小心误入上述限制之一。

您可以亲眼看到，为什么在开发软件时这样使用下划线可能是灾难性的:

尝试像下面这样编译一个简单的 helloWorldd.cpp 程序:

g++ -E helloWorld.cpp

您将看到在后台发生的所有事情:

   ios_base::iostate __err = ios_base::iostate(ios_base::goodbit);
try
{
__streambuf_type* __sb = this->rdbuf();
if (__sb)
{
if (__sb->pubsync() == -1)
__err |= ios_base::badbit;
else
__ret = 0;
}

您可以看到有多少名称以双下划线开头！

另外，如果查看虚拟成员函数，您将看到 * _ vptr 是为虚拟表生成的指针，当您在类中使用一个或多个虚拟成员函数时，将自动创建该指针！但那是另一回事了。

如果你使用下划线，你可能会陷入冲突的问题，你将不知道是什么导致它，直到为时已晚。

小开

旧问题，新答案(C #)。

C # 下划线的另一个用法是使用 ASP.NET 核心的 DI (依赖注入)。在构造过程中分配给注入接口的类的私有 readonly变量应该以下划线开始。我猜是否对类中的每个私有成员使用下划线是一个争论(尽管微软自己遵循它) ，但这一点是肯定的。

private readonly ILogger<MyDependency> _logger;


public MyDependency(ILogger<MyDependency> logger)
{
_logger = logger;
}

编辑:

微软对类中的所有私有成员使用下划线已经有一段时间了。


提交答案