<p>this is a question that when programming I always wonder: What to use when we are writing code: </p>

<pre><code>var myFiles = Directory.GetFiles(fullPath);
</code></pre>

<p>or</p>

<pre><code>string[] myFiles = Directory.GetFiles(fullPath);
</code></pre>

<p><strong><em>var</em></strong> is new and is a <em>Implicitly Typed Local Variables</em>, so we can only use locally and it has rules like can't be null, etc., but I wonder if we get any advantage of using it "normally". </p>

<p>The "normally" part says, not in <strong>Anonymous Types</strong>, <strong>Object and Collection Initializers</strong> and <strong>Query Expressions</strong> where that was the intent to use the var anonymous object, so what I mean is... just like the example above.</p>

<p>what are your thoughts?</p>

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