If your individual methods are so complex that you can't figure out variable names and types I think you got much bigger problems that a var statement :-)

Complexity should be broken down into more manageable chunks that provide logic code abstraction. Usually when that happens parameterization alone makes it clear what the types are.

+++ Rick ---

>>Up front declaration of dynamic results like LINQ make little sense. Sometimes there simply is no hard type you can cast to because the result is anononymous. That's what the var type inferrance is all about...
>>
>>If find up front declarations both distracting (noise and extra code at the beginning of a method) and inhbiting work flow. Everytime you declare a new variable you have to move up to the top to add the declaration first - that's quite a bit of extra work IMHO, that doesn't yield any appreciable improvement in readability.
>
>I understand that but, IMHO, I did find more advantages doing it within a respective order. For example, if I would see more examples like that on the net, it would be much easier for me, at least, to understand what is being declared and how. This reminds me when I see a line which contains a line, within a line, within a line... This makes it extremely difficult to maintain as we have to break it up. Some developers try to develop an entire application in one single line. :) At least, this is the feeling I get when I see some samples like that over the net. Thanks for the feedback, this is always appreciated.
>
>>In Visual Studio you can ALWAYS know what a value's type is regardless of how it was declared. Just hover over the variable and Intellisense will show you what it's cast to even if it's declared as var.
>
>...for as long as this is the environment. Once moved into a new development environment, such as was the case from VFP to .NET, proprietary design environment might not apply.