码迷,mamicode.com
首页 > 编程语言 > 详细

C# 语言习惯

时间:2017-04-24 23:12:22      阅读:188      评论:0      收藏:0      [点我收藏+]

标签:public   字符串   null   

一、使用属性而不是可访问的数据成员

 

二、使用运行时常量(readonly)而不是编译时常量(const)

  1. C# 有两种类型的常量:编译时常量和运行时常量。

  2.尽量使用运行时常量,而不是编译时常量。

技术分享

        /// <summary>
        /// 编译时常量        /// </summary>
        public const int Num = 100;        /// <summary>
        /// 运行时常量        /// </summary>
        public static readonly int Year = 2017;

技术分享

  3.编译时常量只能用于数字和字符串,运行时常量也是一种常量,因为在构造函数执行后它不能被再次修改。

  4.const 比 readonly 效率高,但灵活性低。

 

三、推荐使用 is 或 as 操作符而不是强制类型转换

  1.as 比强转更加高效、安全。

  2.as 操作符不能配合值类型使用,因为值类型永远不可能为 null。

 

四、使用 Conditional 特性而不是 #if 条件编译

 

五、为类型提供 ToString() 方法

  1.应该为类型提供一个合适的 ToString() 版本,否则使用者会根据类的一些属性来自行构造并用于显示。

  2.object 默认提供的 ToString() 方法会返回类型的完整名称,意义不大。如:System.Drawing.Rect。

  3.重写所有类型的 ToString(),可以简单明了的显示对象的摘要信息。

 

六、理解几个等同性判断之间的关系

  1.系统提供 4 种函数判断两个对象是否“相等”。

技术分享

  2.对于前两种方法,我们永远不要重新定义,我们通常要重写 Equals 方法。

  3.重写 Equals 的类型也要实现 IEquatable<T>,如果是结构体的话需要实现 IStructuralEquatable。

  4.引用同一个 DataRow,会认为相等,如果想比较内容的话,而不是引用地址,那么就应该重写 Equals() 实例方法。

  5.Equals() 实例方法的重写原则:对于所有的值类型,都应该重写 Equals() 方法,对于引用类型,如果不能满足需要时才去重写该方法。重写该方法的同时也需要重写 GetHashCode() 方法。

  6.operator == ():只要创建的是值类型,都必须重新定义 operator == (),因为系统默认是通过反射来比较两个值是否相等,效率过低。

 

七、理解 GetHashCode() 的陷阱

  1.对于我们实现的大多数类型来说,避免实现 GetHashCode()。

  2.GetHashCode() 的重载版本必须遵循以下三条原则:

  (1)如果两个对象相等(由 operator == 定义),那么它们必须生成相同的散列码。

  (2)对于任何一个对象 A,A.GetHashCode() 必须保持不变。

  (3)对于所有的输入,散列函数应该在所有整数中按照随机分布生成散列码。

 

八、推荐使用查询语法而不是循环

  示例:

技术分享

            //1.使用循环
            var foo = new int[100];            for (int i = 0; i < 100; i++)
            {
                foo[i] = i * i;
            }            //使用查询语法
            var foo2 = (from n in Enumerable.Range(0, 100) select n * n).ToArray();

技术分享

  1.有些方法语法没有对应的查询语法,如 Take、TaskWhile、Skip、SkipWhile、Min、Max 等,就需要使用方法语法。

 

九、避免在 API 中使用转换操作符

 

十、使用可选参数减少方法重载的数量

  1.对于程序集的第一次发布,可以随意使用可选参数和命名参数。而在进行后续发布时,必须为额外的参数创建重载。这样才能保证现在的程序仍能正常运行。此外,在任何的后续发布中,都要避免修改参数的名称,因为参数名称已经成为公有接口的一部分。

 

十一、理解短小方法的优势

  1.我们最好尽可能地编写出最清晰的代码,将优化工作交给 JIT 完成。一个常见的错误优化是,我们将大量的逻辑放在一个函数中,以为这样可以减少额外的方法调用开销。

技术分享

        public string Test(bool isTrue)
        {            var sb = new StringBuilder();            if (isTrue)
            {
                sb.AppendLine("A");
                sb.AppendLine("B");
                sb.AppendLine("C");
            }            else
            {
                sb.AppendLine("E");
                sb.AppendLine("F");
                sb.AppendLine("G");
            }            return sb.ToString();
        }

技术分享

  在第一次调用 Test 方法时, if-else 的两个分支都被 JIT 编译,而实际上只需要编译其中一个,修改后:

技术分享

        public string Test2(bool isTrue)
        {            var sb = new StringBuilder();            if (isTrue)
            {                return Method1();
            }            else
            {                return Method2();
            }
        }

技术分享

  现在进行了方法拆分,这两个方法就可以根据需要进行 JIT 编译,而不必第一次进行全部编译。

  2.可以将 if-else 分支中有超过几十条的语句,或者某个分支专门用来处理程序发生的错误,或者 switch 语句中的每个 case 中的代码进行选择性的提取。

  3.短小精悍的方法(一般包含较少的局部变量)会让 JIT 更容易地进行寄存器选择工作,即选择哪些局部变量放在寄存器中,而不是栈上。

  4.尽量编写短小精悍的方法。


C# 语言习惯

标签:public   字符串   null   

原文地址:http://hzz333.blog.51cto.com/12844012/1918822

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!