I'm doing a small internship at a business and in their code I find classes that are named like this:
我在一家公司做一个小型实习，在他们的代码中，我找到了这样命名的类:
public class FlagsConfig
{
private static FlagsConfig _instance;
}
Is the _instance a naming convention of any sort in C#?
_instance是c#中任何类型的命名约定吗?
I would ask the developers but they are all out today and the next week on some course.
我会问开发人员，但他们今天和下周都有课。
12 个解决方案
#1
33
Maybe this can help you: .net Naming Conventions and Programming Standards - Best Practices
也许这可以帮助您:.net命名约定和编程标准——最佳实践
According to this document, it is ok.
根据这份文件，它是可以的。
#2
26
For private members, there are lots of different conventions. Some people like prefixes, some don't (personally I don't). Some like to differentiate between instance variables and static variables, others don't:
对于私人成员来说，有很多不同的约定。有些人喜欢前缀，有些人不喜欢(我个人不喜欢)。有些人喜欢区分实例变量和静态变量，有些人不喜欢:
private string m_foo;
private static string s_foo;
Personally I find the underscores get in the way when I'm reading the text - and I firmly believe it depends on how you read; I subvocalize when I read, and the extra bits get in the way of that. For others, it's clearly not a problem. Others find the lack of distinction between local variables and member variables a problem - I typically write short methods where it's obvious what's what anyway.
就我个人而言，我发现下划线阻碍了我阅读文本——我坚信这取决于你如何阅读;当我读的时候，我默念，多余的部分就会阻碍我的阅读。对其他人来说，这显然不是问题。另一些人发现局部变量和成员变量之间缺乏区分是一个问题——我通常会写一些简单的方法，很明显什么是什么。
What's more important - certainly if you're creating an API etc is the naming of publicly visible members (which includes protected ones, and parameter names) at which point you should look at the Microsoft guidelines.
更重要的是——当然，如果您正在创建一个API等，那么您应该查看微软的指导方针，其中包括公开可见的成员(包括受保护的成员和参数名)。
#3
19
Is the _instance a naming convention of any sort in C#?
_instance是c#中任何类型的命名约定吗?
First off, a number of people have referenced the naming guidelines. Note that many of those guidelines apply only to the public surface area of a type. Private members like the one you mention are internal implementation details and therefore subject to the policies of the organization that produced them, not subject to the framework design guidelines for what people expect to see in a public element.
首先，许多人已经参考了命名指南。注意，这些指导原则中有许多只适用于某一类型的公共表面积。像您提到的这样的私有成员是内部实现细节，因此受制于产生它们的组织的策略，而不受人们期望在公共元素中看到的框架设计指导方针的约束。
For private implementation details the underbar prefix is common in many organizations. I personally don't think it is necessary, but some people seem to like it.
对于私有实现细节，在许多组织中，下杠前缀是常见的。我个人认为没有必要，但有些人似乎喜欢它。
What is important however is that even for private implementation details you should never use two underbars. The C# compiler team reserves the right to make any word that begins with two underbars to have any meaning we choose in some future version of the language. That is our "escape hatch" in case we really, really need to add a new non-contextual reserved keyword and really, really do not want to break any existing code.
然而，重要的是，即使对于私有实现细节，也不应该使用两个下划线。c#编译器团队保留制作任何以两个下划线开头的单词的权利，以便在将来的语言版本中具有我们所选择的任何意义。这是我们的“escape hatch”，如果我们真的需要添加一个新的非上下文保留关键字，真的，真的，真的不想破坏任何现有的代码。
This is documented in section 2.4.2 of the C# 4 specification.
c# 4规范的第2.4.2节对此进行了说明。
#4
13
Yes, that is a common naming standard for private fields:
是的，这是私人领域通用的命名标准:
http://csharpguidelines.codeplex.com/
http://csharpguidelines.codeplex.com/
I happen to agree with @JonSkeet that the underscores are messy, but AFAIK that is the MS standard. The document he links to indicates not using underscores in your library, but I believe that is referring to public members.
我碰巧同意@JonSkeet的观点，下划线很乱，但这就是MS标准。他链接到的文档表明在您的库中没有使用下划线，但我认为这是指公共成员。
Update
更新
The first link actually advocates the opposite; don't use underscores. My mistake, but it's still a useful resource.
第一个联系实际上是相反的;不要使用下划线。我的错误，但它仍然是一个有用的资源。
In deference to Mr. Skeet, I followed his link further to: http://msdn.microsoft.com/en-us/library/ms229012.aspx which also states that you shouldn't use underscores, but that guidance applies to static, protected and public members, but not necessarily to private members.
出于对斯凯特的尊重，我将他的链接进一步链接到:http://msdn.microsoft.com/en-us/library/ms229012.aspx，该链接还声明不应该使用下划线，但该指导适用于静态、受保护和公共成员，但不一定适用于私人成员。
Bottom Line: Yes it is a common standard, but first use any internally agreed upon standard before trying to find/use external standards.
底线:是的，这是一个通用标准，但是在尝试寻找/使用外部标准之前，首先使用任何内部商定的标准。
#5
8
There are many guidelines and standards to choose from, but if the standard used at your workplace uses underscores, then that is what you need to use. Especially if you are only doing an internship there, the goal should be to keep things consistent (within that business) rather than following some standard which is "better" (but different).
有许多指导方针和标准可供选择，但是如果在您的工作场所使用的标准使用下划线，那么这就是您需要使用的。特别是如果你只是在那里实习的话，目标应该是保持事情的一致性(在这个行业内)，而不是遵循一些“更好”(但不同)的标准。
Perhaps the better question to ask your developers (or the higher up bosses) is if they have any documentation/links on the standards that they do use?
也许更好的问题是问你的开发人员(或更高级别的老板)他们是否有关于他们所使用的标准的文档/链接?
#6
4
_name is messy, confusing and very old-style. don't do it.
名字是混乱的，混乱的和非常古老的风格。不要这样做。
.NET 4.0 General Naming Conventions http://msdn.microsoft.com/en-us/library/ms229045.aspx
。net 4.0通用命名约定http://msdn.microsoft.com/en-us/library/ms229045.aspx
as you can see, MSDN states
如您所见，MSDN声明
Do not use underscores, hyphens, or any other nonalphanumeric characters
不要使用下划线、连字符或其他非字母数字字符
#7
4
That is relatively common in my experience. To help identify particular kinds of variables (privates, method parameters etc.), a developer may employ different naming conditions.
这在我的经验中比较普遍。为了帮助识别特定类型的变量(私有变量、方法参数等)，开发人员可以使用不同的命名条件。
e.g.
如。
- VariableName
- VariableName
- variableName (camel case)
- variableName(驼峰式大小写)
- _variable
- _variable
- VARIABLE_NAME
- VARIABLE_NAME
It tends to vary by company I think.
我认为每个公司的情况都不同。
#8
3
I like to use a case change to distinguish between fields and properties:
我喜欢用case change来区分字段和属性:
// A private field
private Boolean someValue;
// A public property, exposing my private field
public Boolean SomeValue {
get { return someValue; }
set { someValue = value; }
}
#9
3
Are your co-workers ex-VB devs? In VB.Net the underscore is used regularly for private members of properties or classes. Since VB is case insensitive, you can't use case to distinguish.
你的同事是前vb开发人员吗?在VB。Net下划线通常用于属性或类的私有成员。因为VB是大小写不敏感的，所以你不能用例来区分。
Private _someValue As Boolean
Protected Property SomeValue() As Boolean
Get
Return _someValue
End Get
Set(ByVal value As Boolean)
_someValue = value
End Set
End Property
Update: As an aside, many classes in the .NET source code use this convention. Especially in System.Web.
更新:顺便提一下，. net源代码中的许多类都使用这种约定。尤其是在包含。
#10
2
There are two common conventions.
有两个常见的约定。
the first is "User underscore as field marker" the second is "Use s_ for static fields and m_ for intance fields"
第一个是“用户下划线作为字段标记”第二个是“使用s_用于静态字段，m_用于intance字段”
imo this is a religious question and onnly important thing is to not mix up both styles.
在我看来，这是一个宗教问题，唯一重要的是不要混淆这两种风格。
This book contains many good ideas about convention and design guidelines
这本书包含了许多关于惯例和设计指南的好想法
http://www.amazon.de/Framework-Design-Guidelines-Conventions-Development/dp/0321545613/ref=sr_1_1?ie=UTF8&qid=1320395003&sr=8-1
#11
1
There are many naming conventions that people follow
人们遵循许多命名惯例
myFirstVar = Camel Notation
Camel notaion is generally used for public variables (not private variables).
Camel notaion通常用于公共变量(而不是私有变量)。
MyFirstVar = Pascal Notation
Pascal is generally used for naming Classes and Methods.
Pascal语言通常用于命名类和方法。
str_MyFirstVar = Hungarian Notation // if variable is of type string
Hungarian Notation is considered to be the oldest but not used anymore.
匈牙利表示法被认为是最古老的，但已经不再使用了。
_myFirstVariable = used for private fields in general
#12
1
According to StyleCop [A style/convention checking tool by Microsoft) it shouldn't be done. See: http://stylecop.soyuz5.com/SA1309.html
根据StyleCop[微软的风格/惯例检查工具]，这是不应该做的。参见:http://stylecop.soyuz5.com/SA1309.html
Also, question is a possible dupe of To underscore or to not to underscore, that is the question
同样，问题也可能是为了强调或不强调，这就是问题所在
#1
33
Maybe this can help you: .net Naming Conventions and Programming Standards - Best Practices
也许这可以帮助您:.net命名约定和编程标准——最佳实践
According to this document, it is ok.
根据这份文件，它是可以的。
#2
26
For private members, there are lots of different conventions. Some people like prefixes, some don't (personally I don't). Some like to differentiate between instance variables and static variables, others don't:
对于私人成员来说，有很多不同的约定。有些人喜欢前缀，有些人不喜欢(我个人不喜欢)。有些人喜欢区分实例变量和静态变量，有些人不喜欢:
private string m_foo;
private static string s_foo;
Personally I find the underscores get in the way when I'm reading the text - and I firmly believe it depends on how you read; I subvocalize when I read, and the extra bits get in the way of that. For others, it's clearly not a problem. Others find the lack of distinction between local variables and member variables a problem - I typically write short methods where it's obvious what's what anyway.
就我个人而言，我发现下划线阻碍了我阅读文本——我坚信这取决于你如何阅读;当我读的时候，我默念，多余的部分就会阻碍我的阅读。对其他人来说，这显然不是问题。另一些人发现局部变量和成员变量之间缺乏区分是一个问题——我通常会写一些简单的方法，很明显什么是什么。
What's more important - certainly if you're creating an API etc is the naming of publicly visible members (which includes protected ones, and parameter names) at which point you should look at the Microsoft guidelines.
更重要的是——当然，如果您正在创建一个API等，那么您应该查看微软的指导方针，其中包括公开可见的成员(包括受保护的成员和参数名)。
#3
19
Is the _instance a naming convention of any sort in C#?
_instance是c#中任何类型的命名约定吗?
First off, a number of people have referenced the naming guidelines. Note that many of those guidelines apply only to the public surface area of a type. Private members like the one you mention are internal implementation details and therefore subject to the policies of the organization that produced them, not subject to the framework design guidelines for what people expect to see in a public element.
首先，许多人已经参考了命名指南。注意，这些指导原则中有许多只适用于某一类型的公共表面积。像您提到的这样的私有成员是内部实现细节，因此受制于产生它们的组织的策略，而不受人们期望在公共元素中看到的框架设计指导方针的约束。
For private implementation details the underbar prefix is common in many organizations. I personally don't think it is necessary, but some people seem to like it.
对于私有实现细节，在许多组织中，下杠前缀是常见的。我个人认为没有必要，但有些人似乎喜欢它。
What is important however is that even for private implementation details you should never use two underbars. The C# compiler team reserves the right to make any word that begins with two underbars to have any meaning we choose in some future version of the language. That is our "escape hatch" in case we really, really need to add a new non-contextual reserved keyword and really, really do not want to break any existing code.
然而，重要的是，即使对于私有实现细节，也不应该使用两个下划线。c#编译器团队保留制作任何以两个下划线开头的单词的权利，以便在将来的语言版本中具有我们所选择的任何意义。这是我们的“escape hatch”，如果我们真的需要添加一个新的非上下文保留关键字，真的，真的，真的不想破坏任何现有的代码。
This is documented in section 2.4.2 of the C# 4 specification.
c# 4规范的第2.4.2节对此进行了说明。
#4
13
Yes, that is a common naming standard for private fields:
是的，这是私人领域通用的命名标准:
http://csharpguidelines.codeplex.com/
http://csharpguidelines.codeplex.com/
I happen to agree with @JonSkeet that the underscores are messy, but AFAIK that is the MS standard. The document he links to indicates not using underscores in your library, but I believe that is referring to public members.
我碰巧同意@JonSkeet的观点，下划线很乱，但这就是MS标准。他链接到的文档表明在您的库中没有使用下划线，但我认为这是指公共成员。
Update
更新
The first link actually advocates the opposite; don't use underscores. My mistake, but it's still a useful resource.
第一个联系实际上是相反的;不要使用下划线。我的错误，但它仍然是一个有用的资源。
In deference to Mr. Skeet, I followed his link further to: http://msdn.microsoft.com/en-us/library/ms229012.aspx which also states that you shouldn't use underscores, but that guidance applies to static, protected and public members, but not necessarily to private members.
出于对斯凯特的尊重，我将他的链接进一步链接到:http://msdn.microsoft.com/en-us/library/ms229012.aspx，该链接还声明不应该使用下划线，但该指导适用于静态、受保护和公共成员，但不一定适用于私人成员。
Bottom Line: Yes it is a common standard, but first use any internally agreed upon standard before trying to find/use external standards.
底线:是的，这是一个通用标准，但是在尝试寻找/使用外部标准之前，首先使用任何内部商定的标准。
#5
8
There are many guidelines and standards to choose from, but if the standard used at your workplace uses underscores, then that is what you need to use. Especially if you are only doing an internship there, the goal should be to keep things consistent (within that business) rather than following some standard which is "better" (but different).
有许多指导方针和标准可供选择，但是如果在您的工作场所使用的标准使用下划线，那么这就是您需要使用的。特别是如果你只是在那里实习的话，目标应该是保持事情的一致性(在这个行业内)，而不是遵循一些“更好”(但不同)的标准。
Perhaps the better question to ask your developers (or the higher up bosses) is if they have any documentation/links on the standards that they do use?
也许更好的问题是问你的开发人员(或更高级别的老板)他们是否有关于他们所使用的标准的文档/链接?
#6
4
_name is messy, confusing and very old-style. don't do it.
名字是混乱的，混乱的和非常古老的风格。不要这样做。
.NET 4.0 General Naming Conventions http://msdn.microsoft.com/en-us/library/ms229045.aspx
。net 4.0通用命名约定http://msdn.microsoft.com/en-us/library/ms229045.aspx
as you can see, MSDN states
如您所见，MSDN声明
Do not use underscores, hyphens, or any other nonalphanumeric characters
不要使用下划线、连字符或其他非字母数字字符
#7
4
That is relatively common in my experience. To help identify particular kinds of variables (privates, method parameters etc.), a developer may employ different naming conditions.
这在我的经验中比较普遍。为了帮助识别特定类型的变量(私有变量、方法参数等)，开发人员可以使用不同的命名条件。
e.g.
如。
- VariableName
- VariableName
- variableName (camel case)
- variableName(驼峰式大小写)
- _variable
- _variable
- VARIABLE_NAME
- VARIABLE_NAME
It tends to vary by company I think.
我认为每个公司的情况都不同。
#8
3
I like to use a case change to distinguish between fields and properties:
我喜欢用case change来区分字段和属性:
// A private field
private Boolean someValue;
// A public property, exposing my private field
public Boolean SomeValue {
get { return someValue; }
set { someValue = value; }
}
#9
3
Are your co-workers ex-VB devs? In VB.Net the underscore is used regularly for private members of properties or classes. Since VB is case insensitive, you can't use case to distinguish.
你的同事是前vb开发人员吗?在VB。Net下划线通常用于属性或类的私有成员。因为VB是大小写不敏感的，所以你不能用例来区分。
Private _someValue As Boolean
Protected Property SomeValue() As Boolean
Get
Return _someValue
End Get
Set(ByVal value As Boolean)
_someValue = value
End Set
End Property
Update: As an aside, many classes in the .NET source code use this convention. Especially in System.Web.
更新:顺便提一下，. net源代码中的许多类都使用这种约定。尤其是在包含。
#10
2
There are two common conventions.
有两个常见的约定。
the first is "User underscore as field marker" the second is "Use s_ for static fields and m_ for intance fields"
第一个是“用户下划线作为字段标记”第二个是“使用s_用于静态字段，m_用于intance字段”
imo this is a religious question and onnly important thing is to not mix up both styles.
在我看来，这是一个宗教问题，唯一重要的是不要混淆这两种风格。
This book contains many good ideas about convention and design guidelines
这本书包含了许多关于惯例和设计指南的好想法
http://www.amazon.de/Framework-Design-Guidelines-Conventions-Development/dp/0321545613/ref=sr_1_1?ie=UTF8&qid=1320395003&sr=8-1
#11
1
There are many naming conventions that people follow
人们遵循许多命名惯例
myFirstVar = Camel Notation
Camel notaion is generally used for public variables (not private variables).
Camel notaion通常用于公共变量(而不是私有变量)。
MyFirstVar = Pascal Notation
Pascal is generally used for naming Classes and Methods.
Pascal语言通常用于命名类和方法。
str_MyFirstVar = Hungarian Notation // if variable is of type string
Hungarian Notation is considered to be the oldest but not used anymore.
匈牙利表示法被认为是最古老的，但已经不再使用了。
_myFirstVariable = used for private fields in general
#12
1
According to StyleCop [A style/convention checking tool by Microsoft) it shouldn't be done. See: http://stylecop.soyuz5.com/SA1309.html
根据StyleCop[微软的风格/惯例检查工具]，这是不应该做的。参见:http://stylecop.soyuz5.com/SA1309.html
Also, question is a possible dupe of To underscore or to not to underscore, that is the question
同样，问题也可能是为了强调或不强调，这就是问题所在