>I'd argue that in some ways var makes code *less* portable since it is only accessible within the method where it is created - e.g it can't be used as a return value unless cast to a specific type. Of course you could resort to dynamic but I wouldn't want to go there unless absolutely neccessary :-}

Eh... not so. This works fine:

        public static string HelloWorld()
        {
            var text = "Hello World. Time is: " + DateTime.Now.ToString();
            return text;
        }

The compiler fixes up var to its underlying type. The code is identical and you can definitely return a var local variable. You can't create var properties/fields of course, but for locals the behavior is just like typjng out the full name.

+++ Rick ---

>
>>The benefit of var is that it makes code more portable. If you don't explicitly type something and you later end up changing a type name or new type altogether but keep the interface the same the code still works without further changes to your code or refactoring.
>>
>>Under the covers the compiler does your work for you. It's a minor thing and I used to think it was better to use explicit types, but it saves a few short brain cycles and typing to do something like this:
>>
>>

>>var items = new List<ChmImportItem>();
>>

>>
>>instead of the duplication that is:
>>
>>

>>List<ChmImportItem> items = new List<ChmImportItem>();
>>

>>
>>No less clear what's happening but a bit less typing.
>>
>>+++ Rick ---
>>
>>>Hi all,
>>>
>>>Is there any performance benefits to using or not using var to declare objects?
>>>
>>>Is this better in some way (or not)
>>>

>>>DBRange range = new DBRange();
>>>
>>>over this:
>>>var range = new DBRange();
>>>

>>>Thanks