【问题标题】:What are the best practices for class, method, variable cases/names for objects in C# class library? [closed]C# 类库中对象的类、方法、变量案例/名称的最佳实践是什么? [关闭]
【发布时间】:2016-05-31 03:37:36
【问题描述】:

我是一些小众语言的优秀开发人员,并且正在有机地学习 C#,因此尝试了解最佳实践。

我能否获得一些关于以下示例代码块最适合我构建 Shopify 集成的反馈。

namespace WMShopify
{
    // Is it common to have the namespace and class the same?
    public class WMShopify
    {
        // Are there different practices for private/public vars?
        public string APIKey { get; set; } // Capital
        public string password { get; set; } // lower case
        public string secretString { get; set; } // Camel
        private string _combinedVar; // Camel/underscore for private
    }

    // Should these be in a separate *.cs file?
    public class WMShopifyOrders
    {
        // Method capital/lower/camel?
        public int getOrderCount()
        {
            // lower/capital/camel?
            int localMemberVar = 0;

            return localMemberVar;
        }
    }

    // Should these be in a separate *.cs file?
    public class WMShopifyProducts
    {
        public List<string> getProductList()
        {
            return new List<string>();
        }
    }
}

【问题讨论】:

  • 我发现最佳实践是一致性。如果您或您的团队已经确定了特定的样式指南,则应该遵循它。

标签: c# .net variables namespaces


【解决方案1】:

最佳实践:提出一个所有人都同意并遵循的标准。

判决:书面内联

namespace WMShopify
{
    // Is it common to have the namespace and class the same?

    //No, namespace should probably be the name of the project itself.
    public class WMShopify

    //this looks like a configuration class
    {
        // Are there different practices for private/public vars?
        public string APIKey { get; set; } // Capital
        public string password { get; set; } // lower case
        public string secretString { get; set; } // Camel
        private string _combinedVar; // Camel/underscore for private
    }

    // Should these be in a separate *.cs file?
    // I like to separate them because what happens when you have 100 classes, you just scroll forever?
    public class WMShopifyOrders
    {
        // Method capital/lower/camel?
        // I prefer capital
        public int getOrderCount()
        {
            // lower/capital/camel? Sure
            int localMemberVar = 0;

            return localMemberVar;
        }
    }

    // Should these be in a separate *.cs file? Yup
    public class WMShopifyProducts
    {
        public List<string> getProductList()
        {
            return new List<string>();
        }
    }
}

【讨论】:

  • 我询问类在不同文件中的原因主要是为了数据合同。我使用 json2csharp.com 从 Json 字符串自动创建数据协定类,有时它是大量的小类。
  • 如果您需要生成文件,我建议使用 t4.我有类似的东西,所有类都在一个文件中,它们只是数据合同,所以这并不重要。不过,在常规编码中,我有单独的文件。在上面的示例中,我将它们拆分为单独的文件。
  • 很棒的信息。 t4 现在看起来超出了我的范围。我有一堆随机的 Json 文件,所以从最初的阅读来看,我必须为每个文件编写一个模板?我需要阅读更多内容。
  • 不,您将编写一个模板,该模板将从您的 json 字符串生成所有内容。学习t4。非常值得,而且根本不需要太多时间。
【解决方案2】:

虽然这个问题最终可能会结束,但 MSDN 确实提供了相当广泛的指导方针,大多数 .NET 开发人员在某种程度上都遵循:

https://msdn.microsoft.com/en-us/library/ms229002(v=vs.100).aspx

一些亮点:

  • 不要使用缩写;如果您确实使用首字母缩略词,请仅将第一个字母大写,例如XmlReader,不是XMLReader
  • 对方法和公共字段/属性使用 PascalCase,对私有字段使用 pascalCase,对私有属性支持者使用 _camelCase。
  • 将类保存在一个文件中 - 一个例外是在同一个文件中定义接口及其默认实现
  • 使用动词命名方法(GetSomething()SendSomething(),而不是 Something())。
  • 不要使用GetSet 命名属性,例如Things 很好但不是GetThings
  • 使用“is”(IsEnabledIsReadOnly,而不是 Enabled)命名布尔值。
  • 通用参数一般应使用T,或T(description),例如TSource, TKey, T1/T2/T3

【讨论】:

  • 我询问类在不同文件中的原因主要是为了数据契约。我使用 json2csharp.com 从 Json 字符串自动创建数据协定类,有时它是大量的小类。这算不算例外?
  • 自动生成的类通常是一个例外,因为您不会对其进行编辑或使用重构工具。
  • 很棒的信息。我喜欢这些风格。
猜你喜欢
  • 1970-01-01
  • 2012-12-03
  • 2015-07-05
  • 1970-01-01
  • 1970-01-01
  • 2023-04-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多