C私有成员变量编码标准[关闭]

除了你提到的这两个,在c中没有私人成员的前缀是很常见的。

class Foo
{
    private int i;
    private string id; 
}

这是我用的,也是推荐的 Microsoft's internal naming guidelines .

如所指出的 Brad Abrams: internal coding guidelines :

不为成员使用前缀 变量(变量) _ , m_ , s_ 等)。如果你 想区分本地和 应该使用的成员变量 艾斯 this. 在C和 Me. 在vb.net中。

我认为这里的重要原则是你要始终如一。如果您喜欢这样做,并且它与您使用的其他代码一致,请使用“u”或“m”前缀。无论你选择什么,坚持下去,保持一致。

我更喜欢使用您的第一个示例,或者像这样的自动属性,这样可以完全避免在类中定义私有字段:

public String MyString { get; set; }

使用 prop 使这些非常快的片段。

当我从阅读中回忆起 Framework Design Guidelines ,私有成员变量实际上没有set约定,只是不应使用匈牙利符号,也不应将变量名的第一个字母大写(使用camel大小写)。这本书中的引文支持这两个例子,而且完全不使用任何前缀。

就我个人而言,我更喜欢“m_u”前缀。

微软的一般指导如下:

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

C语言中的自动属性很好,我可以在那时使用,但有些情况下它们不能为我工作,比如在对集合方法进行类型或值检查时。

一般来说:使用驼峰大小写,不要在名字前面加下划线或类型前缀。

public int Age {get; set;}

或

private int age;
public int Age
{
    get { return age; }
    set
    {
        if(value < 0)
            throw new InvalidOperationException("Age > 0");
        age = value;
    }
}

我个人一直用你的第一个例子:

    public class Foo
    {
        private int _i;
        private string _id;
    }

事实上,这就是我整个团队的用意。另外你提到的那个 m_dVal 被称为匈牙利符号,这里是 Wikipedia Entry . 匈牙利符号实际上违反了我们团队的编码标准,所以我从不使用它。

最好是使用项目中已经使用过的东西。如果你开始一个新的项目,使用公司里最常用的东西。

我更喜欢下划线作为私有非常量非只读字段的前缀。为什么?原因: 1。简单地看变量i可以区分字段和/局部变量。对所有字段使用“this”不是一个选项-它更长。 2。参数和字段之间有歧义:

class Foo
{
  private int id;
  public Foo(int id)
  {
    id = id; //Will compile and work fine. But field will not be initialized.
  }
}

我倾向于使用第一个约定,一个简单的下划线。我也没有指定名字中的类型,因为我有智能告诉我它是什么(我知道,它可以是拐杖)。

最好和你的同事或项目团队成员商量一下,决定一个会议,他们中的一些人有点武断。

我不喜欢对成员变量使用任何前缀。对于在方法外部声明的对象,我使用“this.membervariablename”将它们与在方法内部声明的对象区分开来。

C++中的标识符从开始时被认为是不好的练习,它们应该留给内部使用。我想这就是为什么在变量名前面加上前缀有时在C中被认为是不好的做法…虽然没有任何理由你不能这么做,因为所有的.NET内部都被正确封装了,不像C/C++标准库。