C＃现场命名指南？

Question

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

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

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

Answer 1

字段的{p> _camelCase与我所看到的相同（这是我们在我们所使用的地方和Microsoft prefer for the .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的参数而不是this.。 Code Analysis可维护性规则强调了这一点：

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

我的另一个原因是_是可选的（resharper提示你删除它们），如果它没有与局部变量或参数名冲突，那么就知道你正在使用哪个变量更难。如果您在所有私有字段的开头都有{{1}}，那么您始终知道哪个是字段，哪个是本地范围。

Answer 2

关注Microsoft Naming Guidelines。 guidelines for field usage表示它应该是camelCase而不是前缀。请注意，一般规则是没有前缀;具体规则不是前缀来区分静态和非静态字段。

  

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

和（来自General Naming Conventions）

  

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

编辑：我会注意到文档并非针对私有字段具体说明，但表示 protected 字段应仅为camelCase。我想你可以从中推断出私有领域的任何约定都是可以接受的。当然，公共静态字段与受保护字段不同（它们是大写的）。我个人认为，受保护/私有的范围不足以保证命名约定的差异，特别是因为您似乎想要做的就是将它们与参数区分开来。也就是说，如果您遵循受保护字段的准则，则必须在这方面对它们进行不同于私有字段的处理，以便将它们与参数区分开来。 在引用类中的类成员时使用this来区分清楚。

编辑2

我采用了当前作业中使用的约定，即使用下划线为私有实例变量添加前缀，并且通常仅使用PascalCase（通常为autoproperties）将受保护的实例变量公开为属性。这不是我个人的偏好，但是我已经习惯了，并且可能会跟进，直到有更好的事情发生。

Answer 3

通常有两种广泛使用的方法来命名字段（总是使用 camelCase ）：

使用下划线前缀

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

使用this.访问该字段并避免名称冲突

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

我个人更喜欢后者，但我会使用我工作的组织提出的任何惯例。

Answer 4

在我们的商店，我们使用微软建议的私人会员指南启动了我们的第一个C＃项目，即

camelCaseFieldName

但我们很快就陷入了私人成员和参数之间的困惑，并切换到

_camelCaseFieldName

对我们来说效果更好。

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

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

public int PascalCaseFieldName { get; set;}

对于（大多数情况下）遵循MS指南的一套简洁的标准，请查看net-naming-conventions-and-programming-standards---best-practices

Answer 5

Philips Healtcare C# Coding Standard

MSDN - Eric Gunnerson

编辑：我使用“this”关键字来访问C＃和Java中的非静态成员。

Answer 6

最重要的是选择一个标准并坚持下去。在IDesign查看iDesign的C＃编码标准（这是右侧的链接）。这是一个很棒的文档，涵盖了命名指南等内容。他们建议将camel case用于局部变量和方法参数。

Answer 7

简短答案：使用 (t-tolerance..t+tolerance).each { |tt| h[tt] = t } ，即在私有字段中使用前划线。

很长的答案：这里...

很久以前，Microsoft曾经建议对字段使用_privateField。参见here。请注意创建该文档的时间10/22/2008。很古老。

Microsoft的最新代码库却描绘了另一幅图片。

1. 看看.NET CoreFX github存储库的C# Coding style。 ＃3是讨论的重点。这是相关的部分

     

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

2. 还要看看Coding style of Roslyn repository，它专门说明它遵循.NET CoreFX的约定。
3. 再看看.NET standard contributing page，它也说（至少目前如此）遵循与.NET CoreFX相同的指南。
4. CoreCLR还建议遵循与CoreFX相同的指南。
5. 甚至Winforms repo都说使用相同的标准。
6. 我想我已经说够了。因此，总而言之，如果您想遵循Microsoft建议的指南，我认为您知道该怎么做。对于以下专用字段，请使用前导下划线：readonly。

我的意见：我个人也很喜欢在私人领域使用下划线-无需_privateField即可轻松区分。

Answer 8

如前所述，Microsoft Naming Guidelines的剂量不涵盖私有字段和局部变量命名。而且您在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 repos：

private readonly MetricSeries zeroDimSeries;

但是这里是ancient Microsoft implementation of MVC

private IActionInvoker _actionInvoker;

因此，没有关于私有字段命名的任何常规做法或官方准则。只需选择一个并坚持下去即可。

Answer 9

我们使用StyleCop来强制整个代码的一致性。 StyleCop used within Microsoft强制执行一套通用的C＃源代码布局，可读性，可维护性和文档的最佳实践。

您可以在构建时运行StyleCop，并让它为样式违规生成警告。

要回答您的具体问题，私人字段应位于camelCase中，并以“this”为前缀。

Answer 10

遵循Microsoft的命名约定，私有字段应以下划线为前缀。

例如：

private int _myValue;

祝你好运！

Answer 11

我用来区分私有类变量和方法参数的约定是：

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;
}

Answer 12

看看ReSharper。它会突出显示您的名字不符合普通指南的所有地方，并且您可以自定义它。此外，当然还有其他生产力增强的负载和负载。

Answer 13

我这样做;它几乎与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

Answer 14

与V＃相比，我在VB上所做的工作要多得多，所以我想我会从前者到后者继承一些实践（偏见？）。

我喜欢属性的私有字段有一个下划线，尤其是在C＃中，由于区分大小写（无论如何，它是那个？），并且在模块/类范围的变量前加上前缀也使用“ m”来增强其范围。

如果您不喜欢，那么您真的会不是这样：我通常也使用类型前缀（属性字段除外）-“ o”表示对象，“ s”表示表示字符串，“ i”表示整数，等等。

我不能用经过同行评审的论文或其他任何东西来捍卫这一点，但是它对我们有用，这意味着我们不会因外壳或字段/参数混乱而陷入困境。

所以...

Class MyClass

    Private msClassVariable  As String = ""

    Private _classProperty As Integer = 0
    Property Readonly ClassProperty() As Integer
        Get
            Return _classProperty
        End Get
    End Property

    Sub New()

        Dim bLocalVariable As Boolean = False
        if _classProperty < 0 Then _classProperty = 0
        msClassVariable  = _classProperty.ToString()
        bLocalVariable = _classProperty > 0
    End Sub

End Class

Answer 15

我个人使用前缀“ the”修改参数名称，例如theSamplingRate。对我来说，这很合理：）

Answer 16

我对此也有疑问，然后决定检查Microsoft的github代码。我查看过的所有大多数源代码都在私有字段中使用了下划线。

https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/文档似乎没有提及这种用法。

Answer 17

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; 
}