• var


    C# 3新增了关键字“var”。在编译器能明确判断变量的类型时,它允许对 本地类型进行推断。(转)

    开发IDE工具的公司ReSharper的Ilya Ryzhenkov总结了使用var的一些好处 :

    1. 它有利于更好地为本地变量命名。

    2. 它有利于设计更好的API。

    3. 它促使对变量进行初始化。

    4. 它消除了代码的混乱。

    5. 它不需要using指示符。

    RSS Bandit的Dare Obasanjo对此则不敢苟同。由于var给他的开源项目(译注:RSS Bandit项目使用了ReSharper)带来了不利影响,他随后发表了对Ryzhenkov观点的回应 。他回击道:

    有趣的是,这里列出的所有“好处”,主要针对的不仅是形式上的改进, 而且它们之间还相互矛盾。例如,Ryzhenkov宣称var有利于对“更好地为本地变量 命名”,这实际上意味着迫使开发人员使用更长的匈牙利风格的变量命名。颇为滑 稽的是,这种长的变量名完全会加剧代码的混乱,因为这样的变量名是随处可见的,相比 而言,只有在声明变量的时候显示单个的类型名,会保持代码的整洁。那种var有利于 “设计更好的API”的观点实际上如出一辙。因为这种观点主张,如果要求开 发人员使用更长的描述性属性名(例如使用XmlNode.XmlNodeName,而不是XmlNode.Name ),就会达到改进的目的。或许应该有人告知ReSharper的人员,这种将类型信息编码到 变量名中的方式实在是糟透了,而这也正是我们首选强类型编程语言例如C#的原因所在。

    此外,鼓励变量初始化的主张也显得有些不可思议,因为C#编译器对此是强制要求的 。更重要的是,在使用变量之前,通常需要将变量初始化为null,而var关键字对此却不 支持。

    官方C#语言参考中的一行内容佐证了Dare的观点:

    过度使用var会使得源代码晦涩难懂。只有在必要的时候,才推荐使用var,也就是说 当变量用来存储一个匿名类型或者匿名类型集合的时候。

    对于那种var会降低代码可读性的抱怨,并非人人都赞同。Arnon Rotem-Gal-Oz写道:

    对于代码可读性的主张,我更倾向于专注更加强大的方法,例如保持方法简短,有意 义的方法和变量名,以及支持测试(这实际上可以帮助你理解代码是如何运作的 ……)不仅如此,如果你真的非常非常需要代码可读性,ReSharper工具可 以在你的鼠标移动到var关键字之上时,告诉你它的类型;)

    Chris Sutton似乎更进一步,含蓄地指出类型是无关紧要的。

    那么,我的建议是只有当你不知道类型的时候,才使用var。这里是我不同的见解和用 法。请看如下代码片断:

    var procs = from p in ServiceController.GetServices()

    where p.Status == ServiceControllerStatus.Running

    select p;

    procs.ToList().ForEach(p=> Console.WriteLine(p.ServiceName));

    procs的类型无疑为IEnumerable,然而这却与我无关。我首先关注的是procs是一个列 表,列表中的每一项都具有一个属性ServiceName。潜在的类型对于编译器很重要,而那 些不得不去阅读代码的人们却不是编译器,对吗?

    PS:

    1. 必须在定义时初始化。也就是必须是var s = “abcd”形式,而不能是如下形式:
    var s;
    s = “abcd”;
    2. 一但初始化完成,就不能再给变量赋与初始化值类型不同的值了。
    3. var要求是局部变量。
    4. 使用var定义变量和object不同,它在效率上和使用强类型方式定义变量完全一样。
  • 相关阅读:
    uva 11728 Alternate Task
    uvalive 5009 Error Curves
    uva 10341 Solve It
    uva 10870 Recurrences
    uva 11021 Tribbles
    17年9月6日
    React实践相关
    React:Refs and DOM
    React:propTypes
    React:JSX 深入
  • 原文地址:https://www.cnblogs.com/newcoder/p/5039710.html
Copyright © 2020-2023  润新知