Option Infer On or Off?

Question

Possible Duplicate:
Best Practices: Option Infer
What is the best way to mix VB.NET's Option Strict and the new Option Infer directives?

I am developing a old solution, that was translated from VB6 to the VB.NET.

Actually, the default options in files are

Option Strict On
Option Explicit On

I want to use LINQ, and found that is easier to use also the Option Infer On.

Less to write, less (so, easier) to read.

However, a (conservative, from my point of view) part of the team keeps the Option Infer Off and insist do not use it at all, without explicitly explain the causes.

In your opinion, what are the "dangers" of using Option Infer On, along with other two options (Strict and Explicit, both On)?

Answer 1

Code written with Option Infer on is no different in performance or type safety than code written with the same types explicitly declared. With that in mind, the arguments I could come up with against Option Infer are:

• Inconsistency between cases when the type must be specified and when it can be inferred.

  • Class fields for one cannot be inferred, even if initialized inline.
  • Variables holding lambdas (Dim f = Function(x) ...) do not always infer types.
  • Variables that are not initialized must be given a type

  The strength of this argument is directly proportional to the consistency of style in your existing codebase. (For example, I sometimes still use underscores to continue lines when working with older code even when the newer compiler does not require them, if the rest of the code around it uses them.)

• Sometimes the type is not immediately obvious when looking through code.

  Dim temp = Foo() 'temp is type of Foo's return, which is...
  

  Workaround: Declare the variable's type when you feel the need.

  This is not a "danger" as much as a potential inconvenience. More so if you are not working in an environment where Intellisense cannot tell you the inferred type.

• The inferred type may end up being more specific than you really want in that case.

  Workaround: Specifically declare the type you want in that case.

  As the compiler catches cases when this is an issue, I wouldn't call it a "danger" per se. The only time I can think of where this would be an issue the compiler doesn't catch would be if you have different overloads of a method for the base and derived types or are shadowing methods in a derived type. I would argue that either of those cases are problems with the existing code and not with Option Infer.

• The usage of anonymous types that come up in LINQ queries could lead to larger methods than normal as they cannot be passed between methods.

  Workaround: Define named types when this occurs and break up methods as normal.

  This is more of a danger in as much as long methods are dangerous. The usual "how long is too long" discussions apply.

• It makes me look less productive because there are fewer KB in my code files from all those type names I don't have to type. (OK, this one is a joke.)

Answer 2

In my case I prefer having all ON

but having Infer OFF is "ok", you just need to type MORE ;-)

Answer 3

More and more languages infer the type of its variables. Consider C#, F# and possibly a whole host of non-.NET languages as well.

You keep type safety with option infer on. People that like to specify their variables can still do so. But sometimes it is next to impossible and definitely makes reading code harder, with those cryptic names you end up when using LINQ.

I used to be old-school. But when inferring entered the C# world, after a while I simply had to admit it: it improves coding speed, readability, and thus quality and makes it easier to maintain your code. This doesn't mean that you should stop specifying all your variables. In many cases it is still better to specify the types, regardless whether infer is on or off. Again: for readability's sake.

Explain to the old-school people why you'd want it on by default and that they can still type there typenames if they want to.