命名约定 - C++ 中的下划线和 C# 变量

Question

在类字段中经常会看到 _var 变量名。下划线是什么意思？所有这些特殊命名约定都有参考吗？

Answer 1

下划线只是一种约定；而已。因此，每个人的使用总是有些不同。以下是我对这两种语言的理解：

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

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

之前：

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

之后：

public string Name { get; set; }

Answer 2

最佳实践是在 C++ 中的任何变量名称或参数名称之前不要使用下划线

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

如果您读过 C++ 编码标准，您会在第一页看到这样的内容：

“不要过度立法命名，但要使用一致的命名约定：只有两个必须做的事情：a）永远不要使用“卑鄙的名称”，以下划线开头或包含双下划线的名称；“ （p2，C++ 编码标准，Herb Sutter 和 Andrei Alexandrescu）

更具体地说，ISO 工作草案规定了实际规则：

此外，一些标识符被保留供 C++ 实现使用，否则不得使用；无需诊断。 (a) 每个包含双下划线 __ 或以下划线后跟大写字母开头的标识符都保留给实现以供任何使用。 (b) 每个以下划线开头的标识符都保留给实现，用作全局命名空间中的名称。

最好避免以下划线开头的符号，以防您意外陷入上述限制之一。

您可以亲自了解为什么在开发软件时使用下划线可能会造成灾难性的后果：

尝试编译一个简单的 helloWorld.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 是为虚拟表生成的指针，当您在类中使用一个或多个虚拟成员函数时，该指针会自动创建！但这是另一个故事了......

如果您使用下划线，您可能会遇到冲突问题，并且您将不知道是什么原因导致的，直到为时已晚。

Answer 3

实际上，_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

由于许多约定都是针对 .Net 的，并且为了保持 C# 和 VB.NET 约定之间的一致性，因此它们使用相同的约定。

我找到了我所说的参考：
http://10rem.net/articles/net -命名约定和编程标准---最佳实践

带有前导下划线的驼峰式大小写。在
VB.NET，始终指示“受保护”或
“私人”，不要使用“暗淡”。使用
不鼓励使用“m_”，就像使用
与变量名不同的变量名
仅情况下的财产，尤其是
受保护的变量，因为它违反了
遵守，将使您的生活
如果你在 VB.NET 中编程，就像你一样
必须说出你的成员的名字
与某物不同的东西
访问器/修改器属性。其中
这里的项目，前导下划线
确实是唯一有争议的一个。
我个人更喜欢它而不是直接
我的无下划线驼峰式大小写
私有变量，这样我就没有
用“this”限定变量名。
与参数中的区别
构造函数或其他地方我
可能会发生命名冲突。
由于 VB.NET 不区分大小写，这
甚至更重要的是你的
访问器属性通常有
与您的私人会员同名
除下划线外的变量。
就m_而言，它确实只是
关于美学。我（和许多其他人）
发现我丑陋，因为它看起来像那里
是变量名中的一个漏洞。它是
几乎是进攻性的。我曾经用过它
一直都是 VB6，但仅此而已
因为变量不能有
前导下划线。我不可能是
更高兴看到它消失。微软
建议反对 m_ （和
直_）尽管他们都做了
在他们的代码中。另外，前缀为
直接“m”就出来了。当然，
因为他们主要用 C# 编写代码，所以他们可以
拥有仅不同的私人成员
如果从属性来看。 VB 人
必须做点别的事。而不是
尝试想出
逐个语言的特殊情况，我
建议使用前导下划线
所有支持它的语言。如果
我希望我的课堂能够充分
符合 CLS，我可以省略
任何 C# 受保护成员上的前缀
变量。然而在实践中，我
不用担心这个，因为我保留了所有
潜在受保护的成员变量
私有，供应受保护
取而代之的是访问器和修改器。为什么：
简而言之，这个约定是
简单（一个字符），易于阅读
（你的眼睛没有被其他人分散注意力
主角），并成功
避免命名冲突
过程级变量和
类级属性。类级属性。

Answer 4

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

在 C++ 中，使用 _var 约定是不好的形式，因为有一些规则管理标识符前面下划线的使用。 _var 保留作为全局标识符，而 _Var（下划线+大写字母）随时保留。这就是为什么在 C++ 中，您会看到人们使用 var_ 约定。

Answer 5

第一个评论者（R Samuel Klatchko）引用：在 C++ 标识符中使用下划线的规则是什么？ 回答了有关 C++ 中下划线的问题。一般来说，您不应该使用前导下划线，因为它是为编译器的实现者保留的。您在 _var 中看到的代码可能是遗留代码，或者是由使用旧命名系统长大的人编写的代码，该命名系统不支持前导下划线。

正如其他答案所述，它曾经在 C++ 中用于识别类成员变量。然而，就装饰器或语法而言，它没有特殊含义。所以如果你想使用它，它就会编译。

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

Answer 6

老问题，新答案（C#）。

C# 下划线的另一个用途是 ASP NET Core 的 DI（依赖注入）。在构造过程中分配给注入接口的类的私有readonly变量应该以下划线开头。我想这是一个关于是否对类的每个私有成员使用下划线的争论（尽管微软本身遵循它），但这是肯定的。

private readonly ILogger<MyService> _logger;

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

编辑：

Microsoft 对类的所有私有成员采用下划线已经有一段时间了。

Answer 7

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

使用 _field 可以帮助 Intelilsense 过滤所有仅键入 _ 的类变量。

我通常遵循 Brad Adams 准则，但建议不要使用下划线。

Answer 8

对于 C#，Microsoft 框架设计指南 建议不要使用下划线字符来表示 公共成员。对于私有成员，可以使用下划线。事实上，Jeffrey Richter（经常在指南中引用）使用例如 m_，“s_”表示私有静态成员。

就我个人而言，我只使用 _ 来标记我的私人成员。 “m_”和“s_”接近匈牙利表示法，这不仅在.NET中令人不悦，而且可能非常冗长，我发现具有许多成员的类很难按字母顺序进行快速浏览（想象一下 10 个变量都以 m_ 开头） 。

Answer 9

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

Answer 10

我对类的成员变量使用 _var 命名。我这样做有两个主要原因：

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

2）当我寻找类变量时，它对智能感知（或其他代码完成系统）有帮助。只需知道第一个字符就有助于过滤可用变量和方法的列表。

Answer 11

在 C# 中使用它有完全合法的理由： 如果代码也必须可从 VB.NET 扩展。
（否则，我不会。）

由于 VB.NET 不区分大小写，因此没有简单的方法来访问此代码中受保护的 field 成员：

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

例如，这将访问属性 getter，而不是字段：

Public Class VBClass
    Inherits CSharpClass

    Function Test() As Integer
        Return Field
    End Function

End Class

哎呀，我什至不能用小写写 field - VS 2010 只是不断纠正它。

为了使 VB.NET 中的派生类能够轻松访问它，必须提出另一种命名约定。前缀下划线可能是其中干扰性最小且最“历史上接受”的。

Answer 12

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

正如上面的各种示例已经表明的那样，开头的 _ 可能表示 C++ 中类的私有或受保护成员。

让我简单介绍一些可能很有趣的历史琐事。在 UNIX 中，如果您有一个核心 C 库函数和一个内核后端，并且您希望将内核函数公开给用户空间，则 _ 会被固定在直接调用内核函数而不执行任何其他操作的函数存根前面。最著名和最熟悉的例子是 BSD 和 SysV 类型内核下的 exit() 与 _exit() ：其中， exit() 在调用内核的退出服务之前执行用户空间的操作，而 _exit 只是映射到内核的退出服务。

因此 _ 用于“本地”内容，在本例中本地是机器本地的。通常 _functions() 是不可移植的。因为您不应该期望在不同平台上有相同的行为。

现在对于变量名中的 _ ，如

int _foo;

从心理上来说，必须在开头输入 _ 是一件奇怪的事情。因此，如果您想创建一个与其他名称发生冲突的可能性较小的变量名，特别是在处理预处理器替换时，您需要考虑使用 _。

我的基本建议是始终遵循编码社区的惯例，以便您可以更有效地协作。

Answer 13

它只是意味着它是类中的成员字段。

Answer 14

没有特定的单一命名约定，但我见过私人成员的命名约定。

Answer 15

许多人喜欢在私有字段中添加下划线前缀。这只是一个命名约定。

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

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

Answer 16

这只是一些程序员在操作类成员或其他类型的变量（参数、函数的局部变量等）时用来明确说明的约定。成员变量也广泛使用的另一个约定是在名称前添加“m_”前缀。

无论如何，这些只是约定，您不会找到所有这些约定的单一来源。它们是一种风格问题，每个编程团队、项目或公司都有自己的风格（甚至没有）。

Answer 17

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

Answer 18

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

Answer 19

当您阅读代码时，尤其是不属于您自己的代码时，这样的命名约定非常有用。强大的命名约定有助于指示特定成员的定义位置、成员类型等。大多数开发团队采用简单的命名约定，并简单地在成员字段前添加下划线 (_fieldName)。过去，我对 C# 使用了以下命名约定（基于 Microsoft 的 .NET 框架代码约定，可以通过 Reflector 看到）：

实例字段： m_fieldName
静态字段： s_fieldName
公共/受保护/内部成员： PascalCasedName()
私有成员：camelCasedName()

这可以帮助人们在阅读不熟悉的代码时非常快速地理解成员的结构、使用、可访问性和位置。