Question

我在这里看到了一个关于SO而不是命名private/public成员变量的建议，它们的区别仅在于第一个字符的情况。例如：

private string logFileName;

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

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

和：DialogResult dialogResult = this.saveConfigFileDialog.ShowDialog();

和

public Version Version
{
    get;
    set;
}

和

    private void CheckPollingType(PollingType pollingType)
    {

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

感谢。

Answer 1

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

我建议您遵循Naming conventions for C# provided by MSDN和General Naming Conventions provided by MSDN。

具体来说，他们有关于属性的说法：

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

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

不要使用与之匹配的属性   Get方法的名称。

例如，不要为属性命名   EmployeeRecord并命名方法   GetEmployeeRecord。开发人员不会   知道要使用哪个成员来完成   他们的编程任务。

使用a命名布尔属性   肯定的短语（CanSeek而不是   CantSeek）。您也可以选择   带有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

Here is the definitive guidline from Microsoft.

I would also recommend this book if you are at all interested in the details and reasons behind the naming and style conventions used across the .NET framework.

享受！

Answer 6

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

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

现场声明同样符合框架指南，因为它是基于camelCased。关于变量是否应该以{{1}}或_为前缀，偶尔会发生一些宗教争论。这是一个需要在你的小组内解决的问题。

。类型成员的.Net框架设计指南

http://msdn.microsoft.com/en-us/library/ms229012.aspx

Answer 7

我可以认为不使用大小写区分公共成员和私有成员的一个原因是Visual Studio Intellisense会将两个成员紧挨着排序，因此您可能会使用错误的成员而不会注意到。

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

Answer 8

您选择的命名约定 - 保持一致。那么至少当你在六个月后回到代码中，或者当有人第一次看到代码时，他们将能够找出什么是什么。

Answer 9

请注意这种情况：

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 10

同名和不同案例的主要问题是，并非.net中的所有语言都区分大小写，即视觉基础。

这是一个真正问题的唯一情况是，当您公开的成员只会因案例而异时。可以设置一个兼容性属性，以便编译器告诉您是否有这样的场景之一。

上面说过，这并不会影响支持私人成员的情况。

Answer 11

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

Answer 12

如果你只做C＃就没问题了，但是如果你（或你的团队/公司）也在做VB.Net（不区分大小写），那么我建议你不要这么做这可以在C＃中使得不同语言之间的命名约定不会有太大差异。

Answer 13

我看到的两个最受欢迎的约定是使用_或m_作为私有成员变量的前缀。我个人更喜欢m_惯例，但只要它在整个项目/团队中保持一致，我真的不在乎。我不是一个进入'宗教战争'的人：）

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

这允许选择一致且有意义的变量名称，而不会有趣的＆＃39;前缀如_，但也区分本地变量和成员变量。

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

14 个答案: