Option Infer On or Off? [duplicate]

Asked 19/12, 2011 at 15:28 Answered 19/12, 2011 at 17:47

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)?

Carpic answered 19/12, 2011 at 15:28 Comment(10)

I always turn Option Infer off. But yes, I'm old school and "conservative" when it comes to things like this. I'd rather the compiler catch my errors than my having to debug them at run-time. I don't mind the extra typing; between IntelliSense and being able to type quickly, it's not much of a problem. – Opossum 19/12, 2011 at 15:32

As far as the other two, there is absolutely no excuse: Option Explicit and Option Strict should always be on. – Opossum 19/12, 2011 at 15:33

@CodyGray, this is infer, infer work like var in c#, this is compile time error catch – Kidnap 19/12, 2011 at 15:35

For all the people voting to close as "not constructive", I advise switching your vote to "exact duplicate": Best Practices: Option Infer or What is the best way to mix VB.NET's Option Strict and the new Option Infer directives? – Opossum 19/12, 2011 at 15:38

@Fredou: Right, I'm aware of that. I still like to be explicit. Unlike C#, VB.NET doesn't have a var or auto keyword. The syntax with Option Infer looks broken to me, but that's probably because I still work in VB 6 occasionally. I'm all for the compromise of turning Option Infer off at the project-level, but selectively turning it on in individual code files where an extensive use of LINQ actually means that it improves readability. – Opossum 19/12, 2011 at 15:40

@Cody Gray: what about objective (not subjective) observations-differences? – Carpic 19/12, 2011 at 15:51

I'm not really sure how this could be objective. The only thing objective would be contained in the documentation for the Option Infer directive. Whatever it does would be what would change by having it on or off, objectively speaking. Everything else is stylistic and inherently subjective. Not that there's anything bad with talking about style. – Opossum 19/12, 2011 at 15:55

I hate static binding and explicit declarations. And if you have good test coverage (you do have test coverage, don't you?) then catching runtime errors shouldn't be a problem. – Peddle 19/12, 2011 at 17:52

Wow, hating static binding and explicit declarations? I suspect someone might be a scripting language programmer... – Opossum 20/12, 2011 at 0:16

This question differs from the referenced question because it’s about the dangers of Option Infer, not about heather it is a good practice. – Bambi 19/1, 2019 at 11:25

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.)

Rubin answered 19/12, 2011 at 17:47 Comment(0)

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.

Mnemosyne answered 19/12, 2011 at 15:37 Comment(0)

In my case I prefer having all ON

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

Kidnap answered 19/12, 2011 at 15:31 Comment(0)

Recommended topics

Hot tags