C#现场命名指南？

Question

我将自己编写一些C#代码,但我想确保遵循最广泛接受的命名约定,以防我想引入其他开发人员,发布我的代码或出售我的代码.现在我遵循微软设定的命名惯例,因为它们似乎是最广泛接受的.他们没有提到的一件事是为私人领域命名.在大多数情况下,我已经看到它们在camelCase中命名为受保护的字段但是这给我带来了一个问题,因为参数名称应该在camelCase中.以下面的构造函数为例:

public GameItem(string baseName, string prefixName, string suffixName)
{
    //initialize code
}

现在,如果我也将camelCase用于私有字段,则会出现命名冲突,除非我使用"this"来访问类字段(我认为这与大多数标准相反,更不用说更多的输入了).一种解决方案是为参数赋予不同的名称,但是为相同的数据提供2个不同的名称没有逻辑意义.我所知道的唯一一个在C++编码中常见的解决方案是在开头为私有成员提供下划线(_camelCase).C#编码通常接受这种解决方案吗？是否有另一个解决这个问题的方法(比如只使用属性(使用PascalCase)访问字段,即使在类本身中)？

Answer 1

_camelCase对于字段来说,我看到的很常见(这是我们在我们的地方使用的,微软更喜欢.NET Framework).

我个人使用这个标准的理由是,更容易键入_以识别私人领域this.

例如:

void Foo(String a, String b)
{
    _a = a;
    _b = b;
}

与

void Foo(String a, String b)
{
    this.a = a;
    this.b = b;
}

我发现第一个更容易键入,它可以防止我不小心分配给被调用的参数a而不是this.a.这是通过增强代码分析可维护性规则规定:

• CA1500变量名称不应与字段名称匹配.

我的另一个原因是,this.如果它没有与局部变量或参数名冲突,那么它是可选的(resharper会提示你删除它们),从而让你知道你正在使用哪个变量更难.如果您_在所有私有字段的开头都有,那么您始终知道哪个是字段,哪个是本地范围.

Answer 2

遵循Microsoft命名准则.在现场使用指南表明,它应该驼峰,而不是作为前缀.请注意,一般规则是没有前缀; 具体规则不是前缀来区分静态和非静态字段.

不要为字段名称或静态字段名称应用前缀.具体而言,请勿对字段名称应用前缀以区分静态字段和非静态字段.例如,应用g_或s_前缀不正确.

和(来自一般命名约定)

请勿使用下划线,连字符或任何其他非字母数字字符.

编辑:我会注意到文档并不是针对私有字段的,而是表明受保护的字段应该只是camelCase.我想你可以从中推断出私有领域的任何约定都是可以接受的.当然,公共静态字段与受保护字段不同(它们是大写的).我个人认为,受保护/私有的范围不足以保证命名约定的差异,特别是因为您似乎想要做的就是将它们与参数区分开来.也就是说,如果您遵循受保护字段的准则,则必须在这方面对它们进行不同于私有字段的处理,以便将它们与参数区分开来.我用this 在提及班级内的班级成员时,要明确区分.

编辑2

我已经采用了当前作业中使用的约定,即使用下划线为私有实例变量添加前缀,并且通常仅使用PascalCase(通常是autoproperties)将受保护的实例变量作为属性公开.这不是我个人的偏好,但它是我已经习惯的一个,可能会跟随,直到更好的东西出现.

Answer 3

通常有两种广泛使用的命名字段的方法(总是使用camelCase):

使用下划线前缀

void F(String someValue) {
  _someValue = someValue;
}

使用this.访问领域和避免名称冲突

void F(String someValue) {
  this.someValue = someValue;
}

我个人更喜欢后者,但我将使用我工作的组织提出的任何惯例.

Answer 4

简短回答： use _privateField，即对私有字段使用前导下划线。

长答案：这里是...

很久以前，Microsoft 曾经建议使用camelCasefor 字段。见这里。请注意该文档的创建时间，2008 年 10 月 22 日。很古老。

然而，微软最近的代码库描绘了一幅不同的画面。

1. 查看.NET 运行时 GitHub 存储库的C# 编码风格。#3 是正在讨论的点。这是相关的部分

   我们_camelCase用于内部和私有字段，并readonly在可能的情况下使用。

2. 还要看一下Roslyn 存储库的编码风格，它特别指出它遵循 .NET 运行时的约定。
3. 再看看.NET Standard 贡献页面，该页面还表示（至少现在）遵循与.NET CoreFX相同的指南，这是 .NET Runtime 的前身。
4. 在整合之前，CoreCLR还建议遵循与 CoreFX 相同的指南。
5. 甚至WinForms 存储库也谈到使用相同的标准。
6. 我想我已经说得够多了。因此，总而言之，如果您想遵循 Microsoft 建议的指南，我想您知道该怎么做；使用这样的私人领域领先的下划线：_privateField。

我的意见：我个人也更喜欢将下划线作为我的私人字段 - 使它很容易区分，而不需要this.

Answer 5

在我们的商店中,我们使用微软建议的私人会员指南开始我们的第一个C#项目,即

camelCaseFieldName

但是我们很快就陷入了私人成员和参数之间的困惑,并转而使用

_camelCaseFieldName

这对我们来说效果更好.

私有成员通常具有在方法调用之外持久存在的状态 - 前导下划线倾向于提醒您.

另请注意,对属性使用AutoVariable语法可以最大限度地减少对专用支持字段的需求,即

public int PascalCaseFieldName { get; set;}

对于一个非常简洁的标准集(大多数)遵循MS指南,请查看网络命名约定和编程标准---最佳实践

Answer 6

正如所提到的，Microsoft 命名指南不涵盖私有字段和局部变量命名。而且你在微软内部找不到一致性。如果您在 Visual Studio 中生成类或一次性模式，它将创建类似的内容

public MyClass(int value)
{
    this.value = value;
}

或者

private bool disposedValue = false; // To detect redundant calls

protected virtual void Dispose(bool disposing)
{
    if (!disposedValue)
    {
        ...
    }
}

幸运的是，越来越多的代码被微软开放，所以让我们看看他们的代码库，例如ASP.NET Core MVC

private readonly IControllerActivator _controllerActivator;
private readonly IControllerPropertyActivator[] _propertyActivators;

或者.NET Core

private T[] _array;

您可能会说，它实际上不是 Microsoft，而是 .NET Foundation。公平地说，让我们看一下Microsoft 存储库：

private readonly MetricSeries zeroDimSeries;

但这是Microsoft 古老的 MVC 实现

private IActionInvoker _actionInvoker;

因此，关于私有字段命名，没有任何常见的做法或官方指南。只需选择您喜欢的一项并坚持下去即可。