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.

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.

+++ Rick ---

>>What's wrong with the 'var' code you have? The var should work just fine and that's the proper way to declare this actually...
>>
>>If you want to use the explicit type it's IQueryable< Client >.
>
>I think what Naomi is trying to do is the approach I do when designing a class. I like to have my declarations right on top so that I can know right away whatever is used down below such as string, integer and object. Personally, I think this makes the code cleaner, easier to understand later on or from another party thus easier to maintain. I do however faced an obstacle when I first started to play with this Linq stuff. Wherever I saw samples or from the training course I attended, even the teacher was not able to know the proper way to declare the Linq object at the top. The samples, as all the ones I have seen on the net, all contains var declaration as the line Linq level and not on top. Later on I found the proper way to declare all of that and advised him about it. As Linq has some many possibilities, some of the declarations are really difficult to do. Generic is a way to go but that could affect the intellisense. While this may work, if the intellisense does not kick in in the child class, for examples, it makes the Linq coding quite difficult. But, so far, I always found a way to properly define those I needed and benefited from the same as if it would be from a dim declaration directly at the Linq level line.
>
>For me, I like my class to be like this:
>
>Declarations
>Reset of variables/properties (where needed in case we want to have a default if the method is called in loop mode)
>Initialization of variables/properties
>Logic
>Reset of variables/properties (for the ones not applied at the top, and where needed)