C＃字段命名指南？
我将在C＃代码上自己做一些工作，但是我想确保遵循最广泛接受的命名约定，以便让其他开发人员，发布代码或销售我的代码。 现在我正在按照微软已经设定的命名约定，因为它们似乎是最被广泛接受的。 他们没有提到的一件事是为私人领域命名。 在大多数情况下，我已经看到他们在camelCase中命名像受保护的字段，但是这给我一个问题，因为参数名称应该在camelCase中。 以下面的构造函数为例：
public GameItem(string baseName, string prefixName, string suffixName) { //initialize code } 现在，如果我也使用camelCase作为私有字段，除非我使用“this”来访问类字段（我认为这违背了大多数标准，更不用说意味着更多的input），否则会存在命名冲突。 一个解决scheme是给参数一个不同的名字，但是不合逻辑意义的是给相同的数据2个不同的名字。 我所知道的唯一的其他解决scheme在C ++编码中是很常见的，一开始就给私人成员一个下划线。 这种解决scheme通常被C＃编码接受吗？ 有没有解决这个问题的另一种方法（比如只使用属性（使用PascalCase）访问字段，即使在类本身）？
按照Microsoft命名准则 。 领域使用的指导方针表明它应该是camelCase而不是前缀。 请注意，一般规则是没有前缀; 具体的规则是不用前缀来区分静态和非静态的字段。
不要将字首应用于字段名称或静态字段名称。 具体而言，不要将字首应用于字段名称以区分静态字段和非静态字段。 例如，应用g_或s_前缀是不正确的。
和（来自一般命名约定 ）
不要使用下划线，连字符或任何其他非字母数字字符。
编辑 ：我会注意到，文档是不是专用的私人领域，但表明， 受保护的领域应该只骆驼。 我想你可以从中推断出任何私人领域的公约是可以接受的。 当然公共静态字段不同于受保护的（它们是大写的）。 我个人的观点是，保护/私人在范围上没有太大差别，所以在命名习惯上有所不同，特别是你似乎想要做的就是将它们与参数区分开来。 也就是说，如果你按照受保护领域的指导方针，你必须在这方面对待他们比私人领域不同，以区别于参数。 在提到class上的class级成员时，我用 this来区分清楚。
编辑2
我已经采用了我在当前工作中使用的惯例，即使用下划线为私有实例variables添加前缀，通常只使用PascalCase（通常为autoproperties）将受保护的实例variables作为属性公开。 这不是我个人的偏好，但是我已经习惯了，可能会跟随，直到有更好的事情出现。
_camelCase字段是我见过的（这是我们在我们的地方使用和微软更喜欢的.NET框架 ）。
我个人使用这个标准的理由是，键入_来识别私人领域比this.更容易this.
例如：
void Foo(String a, String b) { _a = a; _b = b; }
与
void Foo(String a, String b) { this.a = a; this.b = b; }
我发现第一个更容易打字，它可以防止我意外地分配给参数，而不是this.a 代码分析可维护性规则强化了这一点：
- CA1500variables名称不能与字段名称匹配。
我的另外一个原因就是this. 是可选的（resharper提示你删除它们），如果它不与局部variables或参数名称相冲突，使得知道你正在使用哪个variables更难。 如果你在所有的私人领域的开始有一个_ ，那么你总是知道哪个是一个领域，哪个是有本地范围。
通常有两种广泛使用的方法来命名字段（始终使用camelCase ）：
使用下划线前缀
void F(String someValue) { _someValue = someValue; }
使用this. 访问该字段并避免名称冲突
void F(String someValue) { this.someValue = someValue; }
我个人更喜欢后者，但是我会使用我工作的组织提出的任何约定。
在我们的商店里，我们使用微软build议的私有成员指南开始我们的第一个C＃项目
camelCaseFieldName
但是，我们很快就遇到了私人成员和参数之间的混乱，并转向
_camelCaseFieldName
这对我们来说效果更好。
一个私人成员通常拥有一个在方法调用之外坚持的状态 – 主要的下划线往往会提醒你。
还要注意，使用属性的AutoVariable语法可以最大限度地减less对私人支持字段的需求，即
public int PascalCaseFieldName { get; set;}
对于（主要）遵循MS准则的一组精简的标准，请查看net-naming-conventions-and-programming-standards — best-practices
最重要的是select一个标准并坚持下去。 在IDesign上查看iDesign的C＃编码标准（这是右侧的链接）。 这是一个很好的文档，涵盖命名指南等内容。 他们build议使用骆驼情况下的局部variables和方法参数。
我们使用StyleCop强制整个代码的一致性。 StyleCop 在Microsoft内部使用 ，为C＃源代码的布局，可读性，可维护性和文档实施了一套通用的最佳实践。
您可以在构build时运行StyleCop，并为样式违规产生警告。
为了回答你的具体问题，私人领域应该在camelCase和前缀“this”。
飞利浦Healtcare C＃编码标准
MSDN – Eric Gunnerson
编辑：我使用“this”关键字来访问C＃和Java中的非静态成员。
按照微软的命名约定，专用字段应该以下划线作为前缀。
例如：
private int _myValue;
祝你好运！
我用来区分私有类variables和方法参数的约定是：
private string baseName; private string prefixName; private string suffixName; public GameItem(string baseName, string prefixName, string suffixName) { this.baseName = baseName; this.prefixName = prefixName; this.suffixName = suffixName; }
看看ReSharper。 它会强调你的姓名不符合普通指导原则的所有地方，你可以自定义它。 此外，当然还有其他负载和其他生产力的增强。
我这样做; 这几乎与MSDN一致。
class MyClass : MyBaseClass, IMyInterface { public event EventHandler MyEvent; int m_MyField = 1; int MyProperty { get { return m_MyField; } set { m_MyField = value; } } void MyMethod(int myParameter) { int _MyLocalVaraible = myParameter; MyProperty = _MyLocalVaraible; MyEvent(this, EventArgs.Empty); } }
这里有一些细节： http : //jerrytech.blogspot.com/2009/09/simple-c-naming-convention.html
private string baseName; private string prefixName; private string suffixName; public GameItem(string _baseName, string _prefixName, string _suffixName) { this.baseName = _baseName; this.prefixName = _prefixName; this.suffixName = _suffixName; }
