【问题标题】:A few C# naming convention questions几个 C# 命名约定问题
【发布时间】:2010-11-17 00:51:40
【问题描述】:

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

string MyVar1;

对比

private string MyVar1;

我看到的唯一原因是微软有一天可以将默认访问修饰符更改为public,而不是private

在哪里说私有是可选的?有没有提到MSDN

2) 常量的命名策略?

我在写常量时一直使用大写字母,但是有朋友告诉我这违反了微软的命名政策,是吗?

const string MYVAR1;

const string myVar1;

3) 帕斯卡还是骆驼?

我个人认为骆驼看起来很丑。

【问题讨论】:

  • 只是一个建议,但您可能希望用比“一些 C# 问题”更丰富的信息来重新命名这个问题,以便未来的 SO 用户可以找到他们需要的东西。理想情况下,这将是三个不同的 SO 问题,尽管我确信其中一些问题之前已经被问过。
  • 好点,我更改了标题以更好地表明问题的性质
  • 顺便说一下,THESE_CONSTANT_VARIABLES 是 C++ 中的约定。 (正如上面提到的答案,不是在 C# 中)

标签: c# variables naming-conventions constants private


【解决方案1】:

根据 MS 指南命名 const 的官方建议是:

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

【讨论】:

    【解决方案2】:

    在 C# 中,可见性默认为尽可能有限的可见性。没有修饰符:

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

    因为无论如何尽可能限制可见性是个好主意,所以我尝试始终在我只需要默认可见性的地方去掉修饰符。这使得那些不是默认成员的成员更加明显,这有助于我关注他们是否真的需要如此可见。

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

    一般我会关注微软的Design Guidelines for Developing Class Libraries

    【讨论】:

      【解决方案3】:

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

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

      还请考虑以下示例:

      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 
      } 
      

      【讨论】:

      • 其实我个人确实使用下划线表示私有成员变量(习惯)。我只是指出了微软自己的内部编码指南状态。
      • 微软实际上对 .NET FW 类的私有成员使用了 m_ 前缀。
      【解决方案4】:

      您可能还对 Microsoft 自己的 .NET Framework 内部编码指南感兴趣,revealed by Brad Abrams in his blog

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

      • 不要使用匈牙利符号
      • 不要为成员变量(、m、s_ 等)使用前缀。如果你想区分
      • 在局部变量和成员变量之间应该使用“this”。在 C# 和“我”中。在 VB.NET 中。
      • 对成员变量使用 camelCasing
      • 请使用 camelCasing 作为参数
      • 对局部变量使用 camelCasing
      • 对函数、属性、事件和类名使用 PascalCasing
      • 在接口名称前加上“I”
      • 不要在枚举、类或委托前加上任何字母

      【讨论】:

        【解决方案5】:

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

        来自.NET Framework Developer's Guide Names of Type Members

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

        请注意,此规则不适用于 实例字段。出于以下原因 详细的成员设计 指南,你不应该使用 public 实例字段。

        来自.NET Framework Developer's Guide Capitalization Conventions

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

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

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

        public struct Int32 {
          public const int MaxValue = 0x7fffffff;
          public const int MinValue = unchecked((int)0x80000000);
        }
        

        来自框架设计指南:可重用 .NET 库的约定、惯用语和模式,第二版第 161 页

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

        【讨论】:

          【解决方案6】:

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

          就“Pascal vs. Camel”而言,您遇到了同样的问题。如果你只是自己编程,从头开始,你可以做任何你想做的事情。但是由于您使用的是预先存在的框架,为了保持一致性,您应该模仿相同的风格。此外,一旦习惯了它,您可能会发现遵循相同的规则集实际上会有所帮助,因为您会立即知道某些东西是参数或局部变量(camelCasing)与属性或常量(PascalCasing) .

          【讨论】:

            【解决方案7】:

            私有字段名称也应为驼峰式,可选前缀 _ 或 m_ :

            私人整数计数; 要么 私有字符串_name; 要么 私人小数 m_price;

            【讨论】:

            • 我在 Microsoft 网页上的任何地方都找不到。
            • 这是一种常见的做法 - MSDN 示例中的所有私有字段都是驼峰式的。
            • 我在 MSDN 上也找不到,它只声明应该使用帕斯卡大小写来编写普通变量。它没有说任何关于前缀的内容。有参考吗?
            • _ 和 m_ 破坏了智能感知。它们在 C++ 中可能会有所帮助,但在 C# 中,你是在用它们来打自己的脚。
            • 根据经验,“m_”不会破坏 Intellisense。如果它破坏了你的,那么你的设置有问题。 “m_”实际上非常好,因为一旦你开始输入它,你就会得到所有其他在 Intellisense 中遵循相同命名约定的私有变量
            【解决方案8】:

            没有直接回答你的问题,但也许你会对微软的StyleCop 感兴趣。这是一个根据样式和一致性规则分析源代码的工具。默认情况下,它采用 Microsoft 的样式指南。

            【讨论】:

              【解决方案9】:

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

              Link to ebook download

              不过,就我个人而言,我喜欢明确指定什么时候是私有的,为了可读性,事实上我已经习惯了这样做,以至于当我看不到它时我会感到困惑。至于常量,我使用 PascalCasing。

              【讨论】:

                【解决方案10】:

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

                但是,如果您的类混合了私有、受保护和公共数据成员,那么为了便于阅读,最好指定一个成员是私有的。

                【讨论】:

                  【解决方案11】:

                  你可能对微软的Design Guidelines For Class Library Developers感兴趣

                  【讨论】:

                    【解决方案12】:

                    1)我倾向于使用私有,只是为了明确,但我猜真的没有必要

                    2) 确实,Microsoft 不建议对常量使用大写字母。

                    微软对类型成员的命名约定 gyuidelines 可以找到here

                    【讨论】:

                      【解决方案13】:

                      我怀疑微软是否会改变 C# 成员变量的默认行为。如果没有别的,我会声明你想要私有的东西是私有的,并明确声明你想要公开的东西只是为了清楚起见。

                      我认为常量的重要规则是使用每个人都同意的命名约定,并且您可以将其识别为常量。如果每个人都喜欢全部大写,那么就使用它。如果你想更标准,尽管使用 Pascal 大小写。

                      【讨论】:

                      • 为什么选择 Pascal 而不是 Camel 套管?
                      【解决方案14】:

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

                      2) 不要使用“shouty”常量 - 遵循框架的约定并使用帕斯卡大小写(例如,ThisIsAConstant 优于 THIS_IS_A_CONSTANT)。

                      【讨论】:

                      • 我要补充一点,虽然私有是可选的,但至少在您的代码库中保持一致。也就是说,使用它或不使用它 - 不要混合。
                      • I_AM_AN_OBNOXIOUS_CONSTANT_OOOOH_LOOK_AT_ME_THEN
                      • 我仍然找不到它声明常量不应该全部封顶的地方。
                      • “他们不应该这样做,因为它很烦人且难以阅读。– Rex M 1 分钟前”为什么阅读它们会更难,他们只是注意到“嘿!我是一个常数”
                      • @Rex M. - 标识符的难以辨认是主观的。你不能这么说,因为 发现它们很难阅读,它们实际上就是这样。通过评论“全大写单词很难阅读”,您实际上是在对自己做出陈述,而不是命名约定。事实仍然是您发现它们难以阅读。其他人可以很容易地发现它们更易于阅读。将意见一致视为众所周知的事实是一个常见的错误。无论有多少人分享,主观意见仍然是主观意见。
                      【解决方案15】:

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

                      至于常量,这取决于您的喜好以及与谁合作。但如有疑问,请查看 .NET Framework 以及它们如何命名常量。

                      【讨论】:

                      猜你喜欢
                      • 1970-01-01
                      • 1970-01-01
                      • 2020-03-12
                      • 2017-02-28
                      • 1970-01-01
                      • 1970-01-01
                      • 1970-01-01
                      • 2015-12-13
                      • 1970-01-01
                      相关资源
                      最近更新 更多