几个C#命名约定问题

Question

1） 声明变量的策略是什么？ 您应该始终使用关键字private，还是可以跳过它？

string MyVar1;

我看到的

private string MyVar1;

唯一原因是 Microsoft 有一天可以将默认访问修饰符更改为 public 而不是 private。

哪里说 private 是可选的？ 是否引用了 MSDN？

2） 常量的命名策略？

我在编写常量时总是使用大写字母，但一位朋友告诉我，这违反了微软的命名政策，是吗？

const string MYVAR1;

对比

const string myVar1;

3) 帕斯卡还是骆驼？

就我个人而言，我认为骆驼只是看起来很丑。

Answer 1

1) private 关键字是可选的。 我非常怀疑微软是否会改变字段的默认可见性，因为这将是一个巨大的、突破性的改变（更不用说一个愚蠢的改变了）。 省略 private 关键字只是个人喜好问题。

2) 不要使用“大喊大叫”的常量 - 遵循框架的约定并使用 pascal 大小写（例如 ThisIsAConstant 优于 THIS_IS_A_CONSTANT）。

Answer 2

您可能对 Microsoft 的类库开发人员设计指南< /a>

Answer 3

不直接回答您的问题，但也许您会对 Microsoft 的 StyleCop 感兴趣。 这是一个用于分析源代码的样式和一致性规则的工具。 默认情况下，它采用 Microsoft 的样式指南。

Answer 4

根据 MS 指南命名常量的官方建议是：

• 对包含一两个字符的名称全部使用大写，即 System.Math.PI、System. Math.E
• 对于任何等于或超过 3 个字符的内容，请使用 PascalCasing。

Answer 5

private 是可选的，但需要额外输入。 我喜欢跳过它。

至于常数，这取决于您的喜好以及与您一起工作的人。 但如有疑问，请查看 .NET Framework 以及它们如何命名常量。

Answer 6

我怀疑 Microsoft 是否会更改 C# 成员变量的默认行为。 我会将您想要公开的事物声明为私有，并明确声明您希望公开的事物为公开，只是为了清楚起见（如果没有别的事情）。

我认为常量的重要规则是仅使用每个人都同意并且您认为是常量的命名约定。 如果每个人都喜欢全部大写，那么就使用它。 如果您想更标准，请使用 Pascal 大小写。

Answer 7

private 是可选的，因此您可以跳过它。

但是，如果您的类混合了私有、受保护和公共数据成员，则出于可读性的考虑，指定成员为私有可能是一个好主意。

Answer 8

另外，私有字段名称应该采用驼峰式大小写，可以选择带有前缀 _ 或 m_ ：

    private int count;
or
    private string _name;
or
    private decimal m_price;

Answer 9

就我个人而言，如果常量像其他语言一样全部大写，我会喜欢它......我认为这是一种快速而简单的发现常量的方法。 尽管如此，由于 UsePascalCasing 框架中内置了其他常量，因此您也应该这样做。 一致性非常重要。

至于“帕斯卡与骆驼”，你遇到了同样的问题。 如果您只是从头开始自己编程，您可以做任何您想做的事情。 但由于您使用的是预先存在的框架，为了保持一致性，您应该模仿相同的风格。 此外，一旦习惯了，您可能会发现遵循同一组规则实际上会有所帮助，因为您会立即知道某物是参数或局部变量（camelCasing）与属性或常量（PascalCasing） 。

Answer 10

在字段名称中使用 Pascal 大小写。

来自 .NET Framework 开发人员指南
类型成员的名称

请对所有公众使用帕斯卡大小写
成员、类型和命名空间名称
由多个单词组成。

请注意，此规则不适用于
实例字段。 出于以下原因
详细说明在成员设计中
准则，你不应该使用公共
实例字段。

来自 .NET Framework 开发人员指南
大写约定

请注意常量命名中 Pascal 大小写的隐含标准。

请使用常量字段作为常量
这永远不会改变。

编译器会烧掉 const 的值
字段直接进入调用代码。
因此，const 值永远不能
改变时没有损坏的风险
兼容性。

公共结构 Int32 { 
    公共常量 int MaxValue = 0x7fffffff; 
    公共 const int MinValue = 未选中((int)0x80000000); 
  } 
  

从框架设计指南：可重用 .NET 库的约定、习惯用法和模式，第二版第 161 页，

我找不到任何关于是否应该使用术语 private 来修饰私有字段的参考。 我认为这更多的是一种内部风格选择。 无论您选择哪一个，您都希望保持一致。

Answer 11

1）我倾向于使用私有，只是为了明确，但我想确实没有必要

2）确实如此，微软建议不要对常量使用上限。

可以在此处找到 Microsoft 类型成员的命名约定 gyuidelines

Answer 12

这是一本包含 C# 和 VB .net 编码指南的免费电子书，非常好

电子书下载链接

但就我个人而言，为了便于阅读，我喜欢明确指定某些内容何时是私有的，事实上，我已经习惯这样做了，以至于当我看不到它时我会感到困惑。 至于常量，我使用 PascalCasing。

Answer 13

您可能还对 Microsoft 自己的 .NET Framework 内部编码指南感兴趣，如 ：

遵循针对内部和外部成员的所有 .NET Framework 设计指南。 其中的要点包括：

• 不要使用匈牙利表示法
• 不要使用成员变量的前缀（、m、s_ 等）。 如果你想区分
• 局部变量和成员变量，你应该使用“this”。 在 C# 和“我”中。 在 VB.NET 中。
• 成员变量使用驼峰式命名
• 参数使用驼峰式
• 命名 局部变量使用驼峰式
• 命名 函数、属性、事件和类名使用 PascalCasing
• 接口名称前添加“I”
• 请勿在枚举、类或委托前添加任何字母

Answer 14

@丹·迪普洛
# 不要对成员变量使用前缀（、m、s_ 等）。 如果你想区分局部变量和成员变量，你应该使用“this”。 在 C# 和“我”中。 在 VB.NET 中。

这是很有争议的。 前缀有助于智能感知：您输入前缀字符并仅获取本地私有实例字段的列表。 有了这个。 您将获得一个完整列表，其中包含方法、字段、属性、事件等。

另请考虑以下示例：

private int _count; 
private int total; 
private decimal price; 

public MyClass(int count, int total, decimal price) 
{ 
    _count = count;     // correct 
    this.total = total; // correct 
    price = price;      // wrong! you forgot this. qualifier 
} 

Answer 15

在 C# 中，可见性默认为最有限的可见性。 没有修饰符：

• 非内部类是内部
• 内部类是私有
• 类成员是私有的

因为无论如何尽可能地限制可见性是一个好主意，所以我尝试总是在默认情况下省略修饰符可见性就是我所需要的。 这使得那些不是默认的成员更加明显，这有助于让我关注他们是否真的需要那么可见。

对于常量，我的偏好是将它们放在自己的类中，这样 ClassName.ConstantName 格式就可以清楚地看出它们是什么。

一般来说，我遵循 Microsoft 的开发类库的设计指南。