What to use: var or object name type? [duplicate]

Answer 1

I think it's interesting to note how this is usually handled in Haskell. Thanks to the Curry-Howard isomorphism, the (most general) type of any expression in Haskell can be inferred, and thus type declarations are essentially not required anywhere, with a few exceptions; for example, sometimes you deliberately want to limit the type to something more specific than would be inferred.

Of course, what is required and what is recommended are not the same thing; in practice, the convention seems to be that top-level definitions always have type declarations, while localised definitions have the type declarations left out. This seems to strike a good balance between explicitness-for-readability of the definition as a whole, contrasted with brevity-for-readability of the local "helper" or "temporary" definitions. If I understand correctly, you can't use var for "top-level" definitions (like a method or global function) in the first place, so I guess this translates to "use var everywhere you can" in C# world. Of course, typing "int" is the same number of keystrokes as "var", but most examples will be longer than that.

Answer 2

Personally I only use var in two places:

1. With anonymous types, ie. LINQ-related (where var is required in some cases)
2. When the statement declares and constructs a specific type at the same type

ie. this is an example of point 2:

var names = new List<String>();

Edited: This in response to Jon Skeet's question.

The above answer was in fact simplified. Basically, I use var where the type is either:

1. Unnecessary to know (not that many places though)
2. Impossible to know (LINQ, anonymous types)
3. Otherwise known, or clear from the code

In the case of a factory method, where all you need to know at the place where you write the code is that the object you get back is a descendant of some type, and that some type has a static factory method, then I would use var. Like this:

var connection = DatabaseConnection.CreateFromConnectionString("...");

The above example is a real example from my code. It is clear, at least to me and the people that use this code, that connection is a DatabaseConnection descendant, but the exact type is not needed for neither understanding the code, nor using it.

Answer 3

I tend to use var everywhere, but my co-workers said stop, it is less readable to us. So I now I use var only on anonymous types, LINQ queries and where is constructor on right side.

Answer 4

This post have some good guidlines on when to use var type interface or object types.

Answer 5

You'll get a huge variety of opinions on this one - from "use var everywhere" to "only use var with anonymous types, where you basically have to." I like Eric Lippert's take on it:

All code is an abstraction. Is what the code is “really” doing is manipulating data? No. Numbers? Bits? No. Voltages? No. Electrons? Yes, but understanding the code at the level of electrons is a bad idea! The art of coding is figuring out what the right level of abstraction is for the audience.

In a high level language there is always this tension between WHAT the code does (semantically) and HOW the code accomplishes it. Maintenance programmers need to understand both the what and the how if they’re going to be successful in making changes.

The whole point of LINQ is that it massively de-emphasizes the "how" and massively emphasizes the "what". By using a query comprehension, the programmer is saying to the future audience "I believe that you should neither know nor care exactly how this result set is being computed, but you should care very much about what the semantics of the resulting set are." They make the code closer to the business process being implemented and farther from the bits and electrons that make it go.

Implicitly typed locals are just one small way in which you can deemphasize the how and thereby emphasize the what. Whether that is the right thing to do in a particular case is a judgment call. So I tell people that if knowledge of the type is relevant and its choice is crucial to the continued operation of the method, then do not use implicit typing. Explicit typing says "I am telling you how this works for a reason, pay attention". Implicit typing says "it doesn’t matter a bit whether this thing is a List or a Customer[], what matters is that it is a collection of customers."

Personally I don't tend to use it if the type isn't reasonably obvious - where I include LINQ queries as being "reasonably obvious". I wouldn't do it for Directory.GetFiles for instance, as it's not really obvious that that returns a string[] instead of (say) a FileInfo[] (or something else entirely) - and that makes a big difference to what you do later.

If there's a constructor call on the right hand side of the assignment operator, I'm much more likely to go with var: it's blatantly obvious what the type will be. This is particularly handy with complex generic types, e.g. Dictionary<string,List<int>>.

Answer 6

I tried the "use var everywhere" style... and here is why I didn't continue to use it.

1. Degraded readability at times
2. Limits Intellisense after =
3. Typing "var" really wasn't much shorter than typing "int", "string", etc., especially with intellisense.

With that said, I DO still use it with LINQ.