blocks|key|997716|text|简单地说，它是类中的成员字段。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|997717|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It's simply means that it's a member field in the class.

blocks|key|1212035|text|没有特定的单一命名约定，但我已经看到私有成员的命名约定。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1212036|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

There's no particular single naming convention, but I've seen that for private members.

blocks|key|1212092|text|下划线只是一个约定；仅此而已。因此，它的用法对于每个人来说总是有所不同的。下面是我对这两种语言的理解：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1212093|在C%2B%2B中，下划线通常表示私有成员变量。|1212094|在C#中，我通常只在为公共属性定义底层私有成员变量时使用它。其他私有成员变量不会有下划线。然而，随着自动属性的出现，这种使用在很大程度上已经被淘汰了。|1212095|之前：|1212096|private+string+_name;
public+string+Name
{
++++get+{+return+this._name;+}
++++set+{+this._name+=+value;+}
}|code-block|syntax|javascript|1212097|之后：|1212098|public+string+Name+{+get;+set;+}|1212099|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|U|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|V|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|W|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|P|5|J|7|Y|8|@]|9|@]|A|$K|L]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

The underscore is simply a convention; nothing more. As such, its use is always somewhat different to each person. Here's how I understand them for the two languages in question:

In C++, an underscore usually indicates a private member variable.

In C#, I usually see it used only when defining the underlying private member variable for a public property. Other private member variables would not have an underscore. This usage has largely gone to the wayside with the advent of automatic properties though.

Before:

<pre><code>private string _name;
public string Name
{
 get { return this._name; }
 set { this._name = value; }
}
</code></pre>

After:

<pre><code>public string Name { get; set; }
</code></pre>

blocks|key|1212143|text|根据我的经验(当然有限)，下划线表示它是一个私有成员变量。正如Gollum所说，这将取决于团队。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1212144|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

From my experience (certainly limited), an underscore will indicate that it is a private member variable. As Gollum said, this will depend on the team, though.

blocks|key|1212200|text|我对我的类的成员变量使用_var命名。我这样做的主要原因有两个：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1212201|1)当我稍后阅读代码时，它可以帮助我跟踪类变量和局部函数变量。|1212202|2)在查找类变量时，它在Intellisense+(或其他代码完成系统)中很有用。仅仅知道第一个字符就可以帮助过滤可用变量和方法的列表。|1212203|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I use the _var naming for member variables of my classes. There are 2 main reasons I do:

1) It helps me keep track of class variables and local function variables when I'm reading my code later.

2) It helps in Intellisense (or other code-completion system) when I'm looking for a class variable. Just knowing the first character is helpful in filtering through the list of available variables and methods.

blocks|key|1212245|text|许多人喜欢在私有字段前加上下划线。这只是一个命名约定。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1212246|C#的“官方”命名约定为私有字段指定了简单的小写名称(没有下划线)。|1212247|我不知道C%2B%2B的标准约定，尽管下划线被广泛使用。|1212248|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Many people like to have private fields prefixed with an underscore. It is just a naming convention.

C#'s 'official' naming conventions prescribe simple lowercase names (no underscore) for private fields.

I'm not aware of standard conventions for C++, although underscores are very widely used.

blocks|key|1212278|text|这只是一些程序员在操作类的成员或其他类型的变量(参数、函数的局部变量等)时使用的一种约定。另一个广泛用于成员变量的约定是在名称前加上'm_‘。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1212279|无论如何，这些只是约定，您不会找到所有这些内容的单一来源。它们是一个风格问题，每个编程团队、项目或公司都有自己的(甚至没有)。|1212280|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

It's just a convention some programmers use to make it clear when you're manipulating a member of the class or some other kind of variable (parameters, local to the function, etc). Another convention that's also in wide use for member variables is prefixing the name with 'm_'.

Anyway, these are only conventions and you will not find a single source for all of them. They're a matter of style and each programming team, project or company has their own (or even don't have any).

blocks|key|1212337|text|您可以创建自己的编码指南。只要为团队的其他成员写一个清晰的文档即可。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1212338|只需输入_，使用_field就可以帮助Intelilsense过滤所有类变量。|1212339|我通常遵循Brad+Adams+Guidelines，但它建议不要使用下划线。|offset|length|1212340|entityMap|0|LINK|mutability|MUTABLE|url|http://blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx^0|0|0|5|L|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

You can create your own coding guidelines. Just write a clear documentation for the rest of the team.

Using _field helps the Intelilsense to filter all class variables just typing _.

I usually follow the <a href="http://blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx" rel="nofollow noreferrer">Brad Adams Guidelines</a>, but it recommends to not use underscore.

blocks|key|998150|text|第一个评论者(R+Samuel+Klatchko)提到：What+are+the+rules+about+using+an+underscore+in+a+C%2B%2B+identifier?回答了关于C%2B%2B中下划线的问题。一般来说，您不应该使用前导下划线，因为它是为编译器的实现者保留的。您在_var中看到的代码可能是遗留代码，也可能是由使用旧命名系统的人编写的代码，旧的命名系统不会皱眉前导下划线。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|998151|正如其他答案所述，它曾在C%2B%2B中用来标识类成员变量。但是，就装饰符或语法而言，它没有特殊的含义。所以如果你想使用它，它会被编译。|998152|我将把C#的讨论留给其他人来讨论。|998153|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier^0|40|4|S|1T|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]]|D|@$9|U|A|V|1|W]]|E|$]]|$1|F|3|G|5|6|7|X|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|Y|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|Z|8|@]|D|@]|E|$]]]|K|$L|$5|M|N|O|E|$P|Q]]]]

The first commenter (R Samuel Klatchko) referenced: <a href="https://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier">What are the rules about using an underscore in a C++ identifier?</a> which answers the question about the underscore in C++. In general, you are not supposed to use a leading underscore, as it is reserved for the implementer of your compiler. The code you are seeing with <code>_var</code> is probably either legacy code, or code written by someone that grew up using the old naming system which didn't frown on leading underscores. 

As other answers state, it used to be used in C++ to identify class member variables. However, it has no special meaning as far as decorators or syntax goes. So if you want to use it, it will compile.

I'll leave the C# discussion to others.

blocks|key|1212456|text|如果代码还必须可从VB.NET扩展，则为There+is+a+fully+legit+reason+to+use+it+in+C#:。(否则，我不会。)|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1212457|由于VB.NET不区分大小写，因此在此代码中没有简单的方法来访问受保护的field成员：|style|CODE|1212458|public+class+CSharpClass
{
++++protected+int+field;
++++public+int+Field+{+get+{+return+field;+}+}
}|code-block|syntax|javascript|1212459|例如，这将访问属性getter，而不是字段：|1212460|Public+Class+VBClass
++++Inherits+CSharpClass

++++Function+Test()+As+Integer
++++++++Return+Field
++++End+Function

End+Class|1212461|见鬼，我甚至不能用小写写field+-VS2010只是一直在更正它。|1212462|为了使其易于被VB.NET中的派生类访问，必须想出另一个命名约定。加下划线前缀可能是其中干扰最少且最“历史接受”的一种。|1212463|entityMap|0|LINK|mutability|MUTABLE|url|https://connect.microsoft.com/VisualStudio/feedback/details/89812/cannot-use-c-dlls-with-fields-propertys-which-differ-only-by-case?wa=wsignin1.0^0|K|1A|0|0|10|5|0|0|0|0|C|5|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@$A|13|B|14|1|15]]|C|$]]|$1|D|3|E|5|6|7|16|8|@$A|17|B|18|F|G]]|9|@]|C|$]]|$1|H|3|I|5|J|7|19|8|@]|9|@]|C|$K|L]]|$1|M|3|N|5|6|7|1A|8|@]|9|@]|C|$]]|$1|O|3|P|5|J|7|1B|8|@]|9|@]|C|$K|L]]|$1|Q|3|R|5|6|7|1C|8|@$A|1D|B|1E|F|G]]|9|@]|C|$]]|$1|S|3|T|5|6|7|1F|8|@]|9|@]|C|$]]|$1|U|3|-4|5|6|7|1G|8|@]|9|@]|C|$]]]|V|$W|$5|X|Y|Z|C|$10|11]]]]

<a href="https://connect.microsoft.com/VisualStudio/feedback/details/89812/cannot-use-c-dlls-with-fields-propertys-which-differ-only-by-case?wa=wsignin1.0" rel="nofollow noreferrer">There is a fully legit reason to use it in C#:</a> if the code must be extensible from VB.NET as well.
(Otherwise, I would not.)

Since VB.NET is is case insensitive, there is no simple way to access the protected <code>field</code> member in this code:

<pre><code>public class CSharpClass
{
 protected int field;
 public int Field { get { return field; } }
}
</code></pre>

E.g. this will access the property getter, not the field:

<pre><code>Public Class VBClass
 Inherits CSharpClass

 Function Test() As Integer
 Return Field
 End Function

End Class
</code></pre>

Heck, I cannot even write <code>field</code> in lowercase - VS 2010 just keeps correcting it.

In order to make it easily accessible to derived classes in VB.NET, one has to come up with another naming convention. Prefixing an underscore is probably the least intrusive and most "historically accepted" of them.

blocks|key|998289|text|就C和C%2B%2B语言而言，名称中的下划线(开头、中间或结尾)没有特殊含义。它只是一个有效的变量名字符。这些“约定”来自于编码社区中的编码实践。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|998290|正如上面的各种示例所指出的，_在开头可能表示C%2B%2B中某个类的私有或受保护成员。|998291|让我给出一些可能很有趣的历史琐事。在UNIX中，如果您有一个核心C库函数和一个内核后端，您还想在其中将内核函数公开给用户空间，那么_就会卡在函数存根的前面，该函数存根直接调用内核函数，而不做任何其他事情。最著名和最熟悉的例子是BSD和SysV类型内核下的_exit()和_exit+()：其中，exit()在调用内核的出口服务之前执行用户空间的事情，而_exit只映射到内核的出口服务。|998292|So+_用于“本地”内容，在本例中，local是机器本地的。通常，_functions()是不可移植的。因为你不应该期望在不同的平台上有相同的行为。|998293|现在，对于变量名中的_，例如|998294|int+_foo；|998295|从心理上讲，在开头输入an+_是一件很奇怪的事情。因此，如果您想创建一个与其他变量冲突的可能性较小的变量名，特别是在处理预处理器替换时，可以考虑使用_。|998296|我的基本建议是始终遵循您的编码社区的约定，以便您可以更有效地协作。|998297|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|V|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|W|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|X|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|Y|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|Q|$]]

As far as the C and C++ languages are concerned there is no special meaning to an underscore in the name (beginning, middle or end). It's just a valid variable name character. The "conventions" come from coding practices within a coding community.

As already indicated by various examples above, _ in the beginning may mean private or protected members of a class in C++.

Let me just give some history that may be fun trivia. In UNIX if you have a core C library function and a kernel back-end where you want to expose the kernel function to user space as well the _ is stuck in front of the function stub that calls the kernel function directly without doing anything else. The most famous and familiar example of this is exit() vs _exit() under BSD and SysV type kernels: There, exit() does user-space stuff before calling the kernel's exit service, whereas _exit just maps to the kernel's exit service.

So _ was used for "local" stuff in this case local being machine-local. Typically _functions() were not portable. In that you should not expect same behaviour across various platforms.

Now as for _ in variable names, such as 

int _foo; 

Well psychologically, an _ is an odd thing to have to type in the beginning. So if you want to create a variable name that would have a lesser chance of a clash with something else, ESPECIALLY when dealing with pre-processor substitutions you want consider uses of _.

My basic advice would be to always follow the convention of your coding community, so that you can collaborate more effectively.

blocks|key|1212605|text|现在，对于C#类成员变量，可以使用与this.foobarbaz中相同的"this“表示法。它取代了旧的"m_“或仅"__”表示法。它确实提高了代码的可读性，因为引用的内容是毫无疑问的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1212606|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Now the notation using "this" as in this.foobarbaz is acceptable for C# class member variables. It replaces the old "m_" or just "__" notation. It does make the code more readable because there is no doubt what is being reference.

blocks|key|1212684|text|_var没有任何意义，其目的只是为了更容易地区分变量是私有成员变量。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1212685|在C%2B%2B中，使用_var约定是不好的，因为在标识符前面使用下划线是有规则的。_var保留为全局标识符，而_Var+(下划线%2B大写字母)随时保留。这就是为什么在C%2B%2B中，您会看到人们转而使用var_约定。|1212686|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

_var has no meaning and only serves the purpose of making it easier to distinguish that the variable is a private member variable.

In C++, using the _var convention is bad form, because there are rules governing the use of the underscore in front of an identifier. _var is reserved as a global identifier, while _Var (underscore + capital letter) is reserved anytime. This is why in C++, you'll see people using the var_ convention instead.

It's common to see a <code>_var</code> variable name in a class field. What does the underscore mean? Is there a reference for all these special naming conventions?

Naming convention - underscore in C++ and C# variables

编译器

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

问命名约定-在C++和C#变量中使用下划线
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问命名约定-在C++和C#变量中使用下划线EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问命名约定-在C++和C#变量中使用下划线
EN