一、90%的C#开发者都踩过的坑代码评审吵翻天针对C#开发领域的人而言, 差不多人人皆历经了一种困惑呢: 当着手书写变量之际, 究竟该选用var, 还是采用显式声明类型? 有的人认为var具备简洁且高效的特性, 书写起来不但节省时间而且还省力气有的人则坚决主张显式类型会更加清晰, 对于后期的维护工作而言并不费劲。更让人心里难受的是, 好多开发者用var完全是凭借感觉, 在开会进行代码评审的时候, 你指出他var的使用很杂乱, 他却称你的显式类型过于繁琐, 为此吵个不停没有一个确定的结论, 最终只能这样不了了之。只是, 并没有太多的人明了, var向来都并非是那种所谓「偷懒的捷径」, 然而, 它却是存在于开发者以及编译器之间的一场「无声对话」。编译器很早之前就已经完全摸透了var以及显式类型的底层逻辑, 只不过, 大多数的人都没能读懂它所给出的「暗示」。尤需着重指出的是, 正确挑选 var 以及显式类型, 不但能够使得你的代码更具规范性, 而且还能够削减八成的后续维护繁杂程度, 并且甚者在面试其中会演变成一项加分内容。然而为何依旧会有相当多的人运用不正确呢? 答案, 隐匿于编译器的底层逻辑当中。关键技术补充var是C# 3.0版本引入的隐式类型关键字 , 它属于C#语言本身具备的内置特性 , 不需要额外去安装插件 , 并且完全免费开源 , C#语言是基于.NET框架的 , 而.NET是开源项目。它不是独立的工具 , 所以不存在星级评价 , 不过其底层编译逻辑会和C#语言同步进行更新 , 能兼容所有主流的C#开发环境 , 比如 、Rider等 , 它是每一位C#开发者都必定要掌握的基础知识点。二、核心拆解吃透底层逻辑再也不用凭感觉写代码需明确var以及显式类型的运用方式, 首先要弄明白它们的本质, 两者不存在“谁更具优势谁更为劣势”这种情况, 仅仅存在“场景适配”这一状况, 并且编译器的推断逻辑, 乃是判定场景的关键依据。下面依据原文核心内容以及实操代码, 逐步进行拆解, 使得你看完之后就能够加以运用。1. 隐式类型的本质编译器早就知道你要写什么在C#引入var之前, 开发者声明任何变量时, 都得把类型清清楚楚地写出来。声明字符串要写, 声明整数要写int, 即便编译器早就能够从赋值的右侧, 一下子就看出变量的类型, 开发者依旧得重复书写。比如这样的代码在没有var的时候必须重复写两次// 显式类型声明无var时代 string name C#开发者; int age 28; List hobby new List();可是var的现身, 目的在于去除这般“徒劳之事”, 它促使编译器依据赋值右侧的情形, 自发地推导出变量的类别, 开发者无需再度书写繁杂的类型称谓。关键之处在于: var以及显式类型, 编译之后所得到的结果全然相同, 生成的IL代码, 也就是中间语言, 不存在任何差别, 运行起来同样毫无不同。就像下面的两段代码, 编译以后完全是一样的:// 用var声明 var name C#开发者; var age 28; var hobby new List(); // 显式类型声明 string name C#开发者; int age 28; List hobby new List();不少开发者运用了整整一年的var, 然而却都讲不清楚它的原理, 恰似有人所讲的那般: “我运用var长达一年, 可我却不知原因何在”, 实际上关键就在于那么一句话: var能够让编译器代劳为你“书写”类型, 而非将类型予以取消。2. 关键误区var是静态类型不是动态类型会有这么一点误解的情况, 是非常容易出现的, 那就是在从其他语言转、过来的开发者群体当中, 有不少人会觉得C#的var, 跟那些语言里的var是大同小异的, 并且认为可以毫无限制地给它赋予不同类型的内容, 就好像刚开始能赋值为字符串, 紧接着又能够赋值成整数一样。现实情况却完全相悖了, 那就是, C#里所称的var, 它属于静态类型, 一旦经由编辑器去推断出其具体类型之后, 便会处于固定不变的状态, 要是在后续进行赋值操作时, 赋予的是不一样类型的值, 那么就会直接给出编译出错的提示。看下面的错误示例就能一目了然// 错误示例var一旦推断类型无法更改 var name C#开发者; // 编译器推断为string类型 name 28; // 编译错误无法将int类型隐式转换为string类型在编译器会进行直接提示的情况下, 会出现这样的内容: “ type ‘int’ to ‘’”, 其中这里所呈现的“”存在隐式情况, 实际上是起到提醒作用的, 提醒指向的我们: var所运用的方式是隐式类型推断, 并非隐式类型转换。简而言之, C# 当中的 var 与另一个 var 根本就是截然不同的两码事, 前者指的是“编译器替你撰写类型”, 后者指的是“不存在固定类型”, 这一点务必得区分清楚, 不然极易写出会报错的代码。3. 编译器的底线var不能这样用编译器虽说能够帮我们去推断类型, 然而它也是有着自身那“底线”情形的, 即为唯一在声明变量的时候不进行初始化这种处于禁止状态使用var的那种状况。这归根结底是由于编译器必定要借助通过那个赋值右侧那里边的内容才可以去推断类型, 假使丝毫不存在有能够作为初始值的内容, 那么它也就根本没有办法去进行判断了。看下面的正确与错误对比// 错误示例未初始化编译器无法推断类型 var name; // 报错必须初始化变量 name C#开发者; // 正确示例初始化后编译器正常推断 var name C#开发者;其实, 这个限制, 反倒能够帮着我们去检查代码——要是有开发者尝试着用var声明那种还没有初始化的变量, 那就表明他的代码逻辑说不定是存在问题的啦: 为啥要先去声明变量, 然后才去进行赋值? 是不是存在着逻辑冗余的情况? 好多初级开发者, 就是借助这个问题, 渐渐地规范自身的代码逻辑。4. 核心场景什么时候用var什么时候用显式类型这属于最为实用的部分, 它结合了原文的场景, 还融入了实操代码, 能助力你明确地划分边界, 往后再也无需为此而纠结。1var更清晰的场景在赋值右侧类型极为明显时, 要是显式声明会致使代码变得繁杂、可读性降低, 那么此时使用var最为适宜。特别是在复杂类型以及LINQ查询场景当中, var能够极大程度地简化代码。比如复杂的泛型类型显式声明会非常冗长// 显式声明繁琐且可读性差 Dictionary lookup new Dictionary(); // 用var简洁清晰类型一目了然 var lookup new Dictionary();还有LINQ查询, 它的返回类型常常极为复杂, 像是IEnumerable这种形式它是唯一特别合适的选择, 显式声明不但特别麻烦, 而且还会使代码长度增加, 在这个时候使用var:// LINQ查询场景var是最优选择 var userEvents dbContext.UserEvents .Where(u u.CreateTime DateTime.Now.AddDays(-7)) .GroupBy(u u.UserId);2显式类型更清晰的场景当赋值右边的类型不清晰, 得靠开发者悬停在集成开发环境上才能瞧见类型时, 那就非得用明确的类型——特别是在代码评审阶段, 复审人员没有集成开发环境的悬停功能, 没办法迅速判定类型, 这会对评审效率造成极大的影响。最典型的就是方法返回值场景// 不推荐var无法快速判断GetUserList的返回类型 var users GetUserList(); // 推荐显式类型一眼看清返回类型 List users GetUserList();另外存在数值类型的场景, var会在默认情况下推断成为int, 可是要是实际有需要的话, 显式进行声明能够避免类型转换所产生的错误。// 不推荐var推断为int可能不符合需求 var timeout 30; // 默认为int // 推荐显式声明明确类型需求 double timeout 30; // 明确为double类型 decimal price 99.9m; // 明确为decimal类型三、辩证分析没有绝对的最优解只有合适的选择很多开发者围绕“var与显式类型哪个更具优势”展开争论, 实际上这本身就是一个虚假的命题, 因为两者并不存在绝对的好坏之分, 其关键要点在于能否实现“对场景的适配满足”以及达成“团队内部的共识一致”。那被广泛使用的var所具备的那份价值是毫无异议的, 它能够将代码予以简化, 还能够把冗余的部分予以减少, 特别是在那种复杂类型的场景状况之下, 它能够把开发效率大幅度地予以提升, 进而使得代码变得更加简洁。然而要是对var进行过度的运用, 就会致使代码的可读性出现下降的情况, 特别是针对团队当中的新人而言, 有可能得反反复复地去hover IDE这一工具, 才能够确切明晰变量的类型, 这样一来反倒把理解的成本给增加了。显式类型具备的优势是清晰直观, 不管是谁去看代码, 都能够一眼就明确变量的类型, 进而降低维护以及评审的成本。然而在复杂的场景之下, 显式声明会致使代码变得冗长, 增加不必要的书写量, 甚至对代码的可读性产生影响——如同前面所说的泛型, 显式声明反倒让人望而生畏。更值得去思考的是, 编译器对于你使用var或者是显式类型这一点根本毫不在意, 它能够轻轻松松地推断出正确的类型, 并且顺利地完成编译。真正在乎这件事的, 是和你一同协作的队友, 以及后期维护代码的你自己。你在今天为了图省事而使用的var, 可能会使得半年后的你自己, 或者是刚加入团队的新人, 花费几倍原本所需的时间去理解代码。那么, 问题就出现了: 鉴于不存在绝对的最优解决办法, 我们要怎样才能够平衡两者的使用方法呢? 答案是, 原文里所提及的“一条规则”。有这样一条规则, 它能够解决掉百分之九十的争辩。是什么情况? 是在从事代码书写这一行为的时候, 要再多问自己一回, 问什么? 问“要是不存在集成开发环境的悬停功能的话, 其他的人能够一下子就看明白这个变量的类型究竟是什么吗”。要是看明白了, 使用var那是没有丝毫问题的。要是看不明白, 那就采用显式类型。四、现实意义规范用法让团队协作更高效对于使用C#进行开发的人员而言, 将var与显式类型各自的运用方法区分清楚, 向来都不是为了“展示技巧”, 而是作为提升代码品质、提高协作效能的根基, 特别是在团队开展开发工作时, 规范的变量声明形式, 能够削减海量不必要的交流以及争论。不少团队于代码评审之际吵得不可开交, 关键缘由便是欠缺统一规范: 有的人习惯于运用var, 有的人习惯采用显式类型, 有的人在繁杂场景下选用显式类型, 有的人却在简易场景中过度使用var, 致使代码风格杂乱无章维护成本急剧攀升。实际上, 不管是“在整个过程当中使用var, 仅仅在必要的情况下进行显式声明”, 还是“自始至终采用显式类型, 只有在LINQ等特定场景运用var”, 均不存在问题, 关键之处在于团队能达成一致的认识, 构建统一的规范。一旦制定好了规范 , 每个人按照相同的标准去编写代码 , 不但能够减少评审时产生的冲突 , 而且还可以让代码变得更加整洁 , 更加易于维护的。更加关键的是, 恰当运用var与显式类型, 能够展现出一名开发者的专业水准。一位出色的C#开发者, 不会一味地追求简洁从而过度使用var, 也不会因循守旧进而排斥var, 而是能够依据具体场景灵活地进行选择, 好使代码达成既简洁又明晰的效果。好似诸多资深开发者所讲的那般: “我在C#合并请求里写的代码比其他人都多, 我会问‘这是什么类型? 我无需打开就能知晓。’”,真正出色的代码, 在不需要别人再三去查看方法定义的情况下, 就能够一眼把核心逻辑给看明白, 这, 正是规范运用var以及显式类型的意义所在。五、互动话题你平时怎么用var和显式类型瞥见此处, 想必你已然全然弄明晰了var以及显式类型的深藏底层的逻辑与运用方法, 再也不依靠朦胧直觉去编写代码而且能够在代码审查之际拥有充足依据。把聊视为不妨之事于评论区: 你平常写C#时, 是更倾向于偏爱使用var, 还是显式类型? 有没有遭遇过var设下的坑? 你的团队, 有没有针对var使用而存在的统一规范?还有呀, 倘若你于运用var以及显式类型之际, 存在别的疑问, 或者碰到过难以判定的情形, 同样能够在评论区留言, 一块儿交流探讨, 以使我们所写的代码更为规范、更为高效