Best Practices: Option Infer [closed]

拟墨画扇 提交于 2019-11-28 09:42:08

The type inference used by C# (and thus I presume other .net languages) is very precise (and excellent). The compiler will only allow the statement if the type is clear and unambiguous. Therefore, the outcome is not really a loss in precision ... it is merely that you're saving the developer from stating the type more than once. You're reducing duplication in the code.

(EDIT: Also, it is important to realize that the result is still strongly typed. The compiler knows, at compile time, exactly what type the variable is. There is nothing like a variant involved. If you type var x = 42; it simply figures out that x is an int because you put an int on the right-hand side, thus saving you some typing and duplication).

The only reason future maintenance programmers might not understand it is if they simply don't understand the language feature of type inference in the first place. But I think it is more sound to expect and require that maintenance programmers know the language features, than it is to avoid good language features out of fear that future programmers won't know them.

I guess if you're in a situation where you know that future programmers are junior and not very knowledgeable about the language, then maybe you would avoid some things. But that makes me wonder if you should consider some other language, or even a "platform" like Access which is a hybrid of "real programming" and something that a non-programmer can do some things with.

Here's my recommendation:

If you have already set Option Explicit On and Option Strict On (at whatever level)

  1. Turn off Option Infer in the IDE and project properties
  2. Turn on Option Infer in code files when you need it. This ensures that code is easy to read, and when it is on, it alerts the reader to be on the lookout for its use and reminds them to hover over the var to see its type.

When Option Explicit is Off...

Turning Option Infer On allows old VB6 code full of variants to compile and run better since the compiler assigns a type to the vars at compile time, rather than allowing the var to be late bound. However, testing should be done to ensure that vars do not store multiple types during their lifecycle.

NOTE: This is not a substitute for a proper refactoring of VB6 code ported to dot NET. Variants are bad, children, mm'kay?

Most errors I see have to do with Strict and Explicit, but some occur with Infer. For VB I think this Option Strict On : Option Explicit On : Option Infer Off is the best place to start. It does make writing For Next a bit more cumbersome, but it does mean there will be no question about your intent.

VB.Net type inference cannot be used in aspx pages in Partial Trust environment ...... As often, VB.Net default options make our life harder. In VB9 the useful Option Infer is turned off by default. We cannot write Option Infer On... We cannot write <%@Page ... infer="true"%> at the top of the page... We cannot write in web.config... Someone just forgot about VB.Net.

......

See here: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=321981

I believe it is a safe option because you cannot pass a "Var" type across method boundaries. I am not a big fan of VB or Javascript Variant types, but the Var in C# is quite handy. I would not turn the option off if you plan on using Linq.

--Matt

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!