在成员variables的C＃命名约定
我在这里看到了一个build议，不要用private/public成员variables的名字来区分，只是以第一个字符为例。 例如：
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) {
那么，我听错了吗？ 这些命名约定有什么问题吗？ 如果是的话，那么有什么更好的办法呢？ 链接，引用是一个加号。
谢谢。
这绝对是一个非常stream行的命名约定，我不明白为什么你应该反对它。
我只是推荐遵循MSDN提供的C＃命名约定和MSDN提供的 一般命名约定 。
具体来说，他们有这样的属性说：
使用名词，名词短语或形容词来命名属性。
名词短语或形容词适合于属性，因为属性拥有数据。
不要使用与Get方法的名称匹配的属性。
例如，不要命名一个属性EmployeeRecord，也可以命名一个方法GetEmployeeRecord。 开发人员不知道使用哪个成员来完成他们的编程任务。
用肯定语句（CanSeek而不是CantSeek）来命名布尔属性。 可选地，您也可以在布尔属性中添加Is，Can或Has，但只能添加值。
考虑赋予一个属性与其types相同的名称。
当你有一个强types为枚举的属性时，属性的名称可以和枚举的名字相同。 例如，如果您有一个名为CacheLevel的枚举，则返回其值之一的属性也可以命名为CacheLevel。
我想如果有一个令人信服的理由来反对你的build议，他们会在他们的指导方针中提到它。
大部分时间，类级别的variables都是用下划线作为前缀。 所以myVariable实际上是_myVariable。 很多人不喜欢用一个字来replace名字，因为容易犯错。
只是做myVariable和MyVariable没有任何问题。 这只是一个约定，如果每个人都遵循它，那么它可能会工作得很好。
就个人而言，如果可能的话，我省去了私有variables，只使用属性中的getter和setter。 大部分时间（但不是所有的时间），访问私有variables被用来不允许在属性中写访问。
这可以通过以下方式解决：
public String MyVariable { get; private set; }
通常情况下，我总是看到一个领先_的私人成员。 （假设它不是自动属性）
private string _customerName; public string CustomerName { get{return _customerName;} set{_customerName = value;} }
当然，最终的裁决是你们团队的惯例（假设你不是在做一个孤独的狼项目，
我会用我一直使用的东西把我的帽子戴在戒指上
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 _
这里是来自微软的权威指导。
如果您对.NET框架中使用的命名和样式约定背后的细节和原因感兴趣，我也会推荐这本书。
请享用！
不，这些命名约定没有什么问题。
属性版本实际上是根据.Net框架devise指南推荐的格式。
该字段声明同样符合框架指南，因为它是驼峰式的。 有时偶尔会发生一场宗教性的战争，以至于variables是否应以_或m_为前缀。 这是一个需要在你的小组内解决的问题。
types成员的.Net框架devise指南
我认为不使用大小写区分公共与私有成员的一个原因是，Visual Studio Intellisense会将两个成员排在彼此的旁边，所以您可能会在不注意的情况下使用错误的成员。
话虽如此，我在我的代码中使用了你描述的惯例（用例来区分可访问性），而且我没有任何问题。
什么命名约定你select – 是一致的。 那么至less在六个月的时间里你回到代码中，或者当有人第一次看这个代码的时候，他们就能搞清楚什么是代码。
但请注意这种情况：
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会警告你这种情况，但这不是非法的，有时候可以通过。
不同情况下同名的主要问题是，.net中的所有语言都不区分大小写，即视觉基本。
这是一个真正的问题的唯一场景是当你暴露公众成员，只是大小写而异。 有一个兼容性属性可以设置，所以编译器会告诉你是否有这样的场景之一。
以上说，这并不真正影响后援私人会员的情况。
提出的命名约定的基本问题是，Intellisense将使用属性上的私有variables。 在很多情况下，这实际上并不是一个问题（实际上通常是一件好事），但是对于那些less数情况来说，将这两个名称分开的惯例是有用的。 我喜欢私人成员variablesm_和私人静态variablesc_。
如果你只是在做C＃这没有问题，但如果你（或你的团队/公司）也在做VB.Net（不区分大小写），那么我build议不要在C＃要么使得不同语言之间的命名约定不会有太大的差别。
我所看到的两个最stream行的约定是使用_或m_作为私有成员variables的前缀。 我个人比较喜欢m_的习惯，但只要在整个项目/团队中保持一致，我真的不在乎。 我不是一个进入“宗教战争”:)
由于这个话题在最重要的search结果中popup，我也想分享我的build议：
除了公共/私人成员的Pascal / camelCase约定之外，我总是select由2个或多个单词组成的成员variables名称，以及由单个小写字母或甚至字母组成的局部variables名称。
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; } }
这允许select一致且有意义的variables名称，而不需要像_那样的“有趣的”前缀，而是区分本地variables和成员variables。
