关于C#成员变量的命名约定

Question

我在这里看到了一个关于不要命名 private/public 成员变量的建议，因为它们仅在第一个字符的情况下有所不同。例如：

private string logFileName;

public string LogFileName
{
    get
    {
        return logFilename
    ....

和： private System.Windows.Forms.MainMenu mainMenu;

和： DialogResultDialogResult = this.saveConfigFileDialog.ShowDialog();

以及： 和

public Version Version
{
    get;
    set;
}

：

    private void CheckPollingType(PollingType pollingType)
    {

那么，我是吗？听错了吗？这些命名约定有什么问题吗？如果是，那么有哪些更好的方法呢？链接、参考文献是一个优点。

谢谢。

Answer 1

这绝对是一个非常流行的命名约定，我不明白你为什么应该反对它。

我只是建议遵循 MSDN 提供的 C# 命名约定以及MSDN 提供的通用命名约定。

具体来说，他们对属性有这样的说法：

使用名词命名属性，名词
短语或形容词。

名词短语或形容词是
适合属性，因为
属性保存数据。

不要使用与
Get 方法的名称。

例如，不要命名属性
EmployeeRecord 并命名一个方法
获取员工记录。开发商不会
知道使用哪个成员来完成
他们的编程任务。

请使用以下名称来命名布尔属性
肯定短语（CanSeek 代替
无法寻找）。您还可以选择
为布尔属性添加 Is 前缀，
可以，或有，但仅限于它添加的地方
值。

考虑给予相同的属性
名称作为其类型。

当您拥有的房产是
强类型化为枚举，
属性名称可以相同
作为枚举的名称。为了
例如，如果您有一个枚举
名为 CacheLevel 的属性
返回其值之一也可以
命名为CacheLevel。

我认为，如果有令人信服的理由反对您的建议，他们会在指导方针中提到这一点。

Answer 2

大多数时候，类级别变量前面带有下划线。所以 myVariable 实际上是 _myVariable。很多人不喜欢将名字改成一个字符，因为这样很容易出错。

只执行 myVariable 和 MyVariable 并没有什么问题。这只是一个惯例，如果每个人都遵循它，那么它可能会运作得很好。

就我个人而言，如果可能的话，我会放弃私有变量，而只使用属性中的 getter 和 setter。大多数时候（但并非总是），访问私有变量用于不允许对属性进行写访问。
这可以通过以下方法解决：

public String MyVariable
{
   get;
   private set;
}

Answer 3

通常，我总是看到私有成员以 _ 开头。 （假设它不是汽车财产）

private string _customerName;
public string CustomerName
{
    get{return _customerName;}
    set{_customerName = value;}
}

当然，最终的裁决是你的团队的惯例（假设你没有做一个独狼项目或与彻底的白痴一起工作）

Answer 4

我将用我一直使用的东西来投掷我的帽子

class ClassName //Classes are PascalCase
{
    public ClassName(int myProperty) //Constructor arguments are named the same as the property they set but use camelCase.
    {
       _myProperty = myPropriety;
    }
    public void MyFunction(object varToBePassed) //Function names are PascalCase, passed pramaters are camelCase.
    {
        int sampleVar; //local variables are camelCase
    }
    public int MyProperty { get { return _myProperty; } } // Properties are PascalCase

    private int _myProperty; // Private fields are camelCase and start with a _

Answer 5

这是 Microsoft 的明确指南。

如果您对跨领域使用的命名和样式约定背后的细节和原因感兴趣，我也会推荐这本书.NET 框架。

享受吧！

Answer 6

相同名称不同大小写的主要问题是，并非 .net 中的所有语言都区分大小写，即 Visual Basic。

真正存在问题的唯一情况是当您公开仅因情况而异的公共成员时。可以设置一个兼容性属性，以便编译器告诉您是否存在此类情况之一。

如上所述，这并不会真正影响支持私人成员的情况。

Answer 7

不，这些命名约定没有任何问题。

属性版本实际上是根据.Net框架设计指南推荐的格式。

字段声明同样符合框架指南，因为它是驼峰式的。关于变量是否应该以 _ 或 m_ 为前缀，有时会出现一些宗教战争。不过，这是一个需要在您的团队内解决的问题。

类型成员的 .Net Framework 设计指南

• http://msdn.microsoft.com/ zh-cn/library/ms229012.aspx

Answer 8

我认为不使用 case 来区分公共成员和私有成员的原因之一是 Visual Studio Intellisense 会将这两个成员紧挨着排序，因此您可能会在没有注意到的情况下使用错误的成员。

话虽如此，我在代码中使用了您描述的约定（使用大小写来区分可访问性），并且没有遇到任何问题。

Answer 9

我看到的两个最流行的约定是在私有成员变量前添加 _ 或 m_ 前缀。
我个人更喜欢 m_ 约定，但只要它在整个项目/团队中保持一致，我真的不在乎。我不是一个会卷入“宗教战争”的人:)

Answer 10

无论您选择什么命名约定 - 都要保持一致。然后至少当你在六个月内回到代码时，或者当新人第一次查看代码时，他们将能够弄清楚是什么。

Answer 11

但要小心这种情况：

public class MyClass {
    public int Foo { get; private set; }

    public MyClass(int foo) {
        // oops, setting the parameter to itself, not the property
        foo = foo;
    }
}

Visual Studio 会警告您这种情况，但这并不违法，有时可能会漏掉。

Answer 12

所提出的命名约定的基本问题是智能感知将使用私有变量而不是属性。在许多情况下，这实际上并不是一个问题（事实上，通常是一件好事），但对于少数存在问题的情况，分隔两个名称的约定很有用。我喜欢 m_ 表示私有成员变量，c_ 表示私有静态变量。

Answer 13

如果您只使用 C#，那没问题，但如果您（或您的团队/公司）也在使用 VB.Net（不区分大小写），那么我建议最好不要在 C# 中执行此操作要么这样不同语言之间的命名约定就不会相差太大。

Answer 14

由于这出现在有关该主题的最上面的搜索结果中，我也想分享我的建议：

除了公共/私有成员的 Pascal/camelCase 约定之外，我总是选择由 2 或更多组成的成员变量名称单词，以及由单个小写单词甚至仅一个字母组成的局部变量名称。

public class MyCanvas : Canvas {
    public int CanvasId { get; private set; }
    private double canvasHeight; // member vars consist of 2+ words
    private double canvasWidth;

    public MyCanvas(int id) {
        CanvasId = id;
        double height = ...; // local vars consist of one word/letter
        canvasHeight = height;
    }
}

这允许选择一致且有意义的变量名称，而不需要像 _ 这样的“有趣”前缀，而且还可以区分局部变量和成员变量。