Should I encourage junior developers to use explicit or implicit typing?

Question

I am looking to solicit the community's opinion on whether or not it would be advisable to teach junior developers to code with implicit typing (using var) or should I encourage the use of explicit types.

This is not really a question about the advantages or disadvantages of implicit typing. Junior developers (at least the ones that I deal with) tend to develop very long lasting coding habits in their first years as professional developers and I am trying to think through the potential downside of starting a developer off with the implicit typing approach.

Are there specific scenarios that would warrant the advocacy of explicit typing? What about as part of the discipline of TDD?

And on the issue of ReSharper...

@Eben Geer mentioned ReSharper in his answer. Should we keep the default suggestion to use implicit typing in the inspection templates that our junior developers use?

Answer 1

There's no easy rule to follow. It comes down to the basic principle:

Code should convey its meaning to the reader in the most effective way possible.

The var keyword is one of the techniques you can use. It makes the code more readable in some cases, but less readable in others.

See these two examples:

Dictionary<string, List<Widget>> theDictionary = new Dictionary<string, List<Widget>>();

or

var theDictionary = new Dictionary<string, List<Widget>>();

In this case, the explicit type adds nothing to the readability of the code. You KNOW what type theDictionary is, and it's unnecessary to state the type twice in the same line.

---

But how about this:

var imageData = LoadImageDataFromWidget(widget);

or

Stream imageData = LoadImageDataFromWidget(widget);

Here, the second answer is more readable. You don't automatically know what LoadImageDataFromWidget returns, so the explicit typing gives the reader new and relevant information.

Answer 2

Using var should be about readability - there is no general rule (always use it vs never use it). As such it is a matter of opinion.

You need to instil the focus on readability into your juniors.

It is worth writing statements twice - implicitly and explicitly and comparing them for readability, then keeping the one that is more readable (however subjective that may be).

Answer 3

It's hard to have a general rule of thumb here, as the usage is often a matter of taste.

The only cases where I might say to explicitly type is when you want to refer to an object by an interface or subclass instead.

For example:

// more readable, but does dao need to be exposed as a SqlProductDao?
var dao = new SqlProductDao(); 

vs

// may have benefits in hiding the implementation
IProductDao dao = new SqlProductDao(); 

I've also seen some people recommend not using implicit typing for numeric types.

For example:

var x = 1;  // we know this is int, but do they?

That said, there are cases where implicit typing is much more easy to read than explicitly typing, as is the case with many complex LINQ queries.

My personal rule is to use implicit typing where possible and especially where it improves readability (by reducing redundancy and source density). But if using implicit typing in a particular instance makes the code harder to understand, it's up for debate.

Answer 4

I find Eric Lipperts post on the subject to be highly informative; I would even say ' authorative' :

http://blogs.msdn.com/b/ericlippert/archive/2011/04/20/uses-and-misuses-of-implicit-typing.aspx

Here's the summary, repeated verbatim:

• Use var when you have to; when you are using anonymous types.
• Use var when the type of the declaration is obvious from the initializer, especially if it is an object creation. This eliminates redundancy.
• Consider using var if the code emphasizes the semantic "business purpose" of the variable and downplays the "mechanical" details of its storage.
• Use explicit types if doing so is necessary for the code to be correctly understood and maintained.
• Use descriptive variable names regardless of whether you use "var". Variable names should represent the semantics of the variable, not details of its storage; "decimalRate" is bad; "interestRate" is good.

Answer 5

Good naming also solves a lot. Let's take Andrews example:

var imageData = LoadImageDataFromWidget(widget);

With better naming:

var imageStream = LoadImageStreamFromWidget(widget);

With the better name, suddenly the var is also very readable. Just don't use var for primitives like string, int,...

Answer 6

I don't think you should encourage them to do either, unless you've implemented a coding standard (which to me would be a counter-productive one anyway).

Encourage them to use using, and interfaces, doc comments, and IDispose etc. Things that will make a real difference.

As far as I'm concerned aside from where you have to use var, this has about as much value as an indenting style.

Answer 7

That is a very broad question, but my answer would be both. The old answer would be explicit, but with companies like Microsoft embracing things like node.js and dynamic objects, it seems like a good thing to have knowledge of both and, perhaps more importantly, when to use each.

Answer 8

My personal feeling is it's what comes after the var keyword that matters more. Anybody can look to the right of that statement and either through intellisense or through the declaration understand what the object is, but I think the name of the var matters more to me.

Answer 9

If the junior developers are not familiar with the concept of explicit versus implicit typing, I would suggest encouraging explicit typing. Once that falls into the category of rote knowledge, I would introduce implicit typing and explain the different camps of thought and possible advantages and disadvantages of the practice.

I mean, fundamentally, "var" is a syntactic shortcut, and I think that it's better, in general, for people who are learning first to learn the "standard" way and then to learn shortcuts. I'd encourage "learn and master explicit first and then learn this shortcut once your discretion can be trusted" for this in the same way that I'd encourage learning basic HTML before using a designer or learning the fundamentals of databases and querying before using an ORM. I prefer that people taking shortcuts know what they're 'shortcutting' whenever possible and practical.

Answer 10

Implicit typing in C# was created to support the projection of data into new anonymous types in LINQ queries. However, many developers use it to save typing or to improve readability. The more important thing would be to teach your junior developers to use ReSharper which will make explicit typing much easier to type (on the keyboard) than implicit typing.

UPDATE

The following article gives a good breakdown about the relation between var, the compiler, and LINQ:

Albahari: LINQ Myth #1

Answer 11

Depends. I'd say use explicit typing as a general rule of thumb, simply because it can make code a lot clearer. Plus, you may need it explicitly when assigning to a base class or interface:

IEnumerable<string> e = SomeObject.SomeList; // Not really a great example since List<T> doesn't hide anything from IEnumerable<T>, but oh well.

as opposed to doing the ugly (IMHO):

var e = (IEnumerable<string>)SomeObject.SomeList; // Also a lot longer.

Then there's the matter of compatibility - explicit typing can be used in older versions of C#. So I would say, use explicit typing, except when implicit typing is much more convenient or is necessary.

Answer 12

Using an untyped language (PHP) for most recent projects, I can say that choosing meaningful method names goes a long way. Specifying the type of the variable requires more work when refactoring than changing the name of a method. A name like LoadImageFromFileAsStream can tell you everything you need to know and shield you from having to track down the type declarations when you change it to LoadImageFromFileAsByteArray.

Answer 13

if you do the later.. I would explain that doing something like this

  var lstColumns = new List<string>(); 

  is the same as doing 
  List<string> lstColumns = new List<string>()

Answer 14

Personally I do a mixture of both. When I'm declaring fields on a local scope I do

StringBuilder sb = new StringBuilder();

For example, so the type is explicitly specified for readability. However, when I'm iterating over a collection, like so:

List<object> Objects = new List<object>();

foreach (var o in Objects)
{
    // Do something
}

Since, by looking at the collection it is iterating over, I can already make out the type quite easily, thus I find it superfluous to explicitly define the type in the loop itself.

I mostly apply this only when I'm working on projects other people will have to work with as well, so they don't have to second guess themselves which types they are working with, instead it's all there for them. When I'm developing projects I will only work on myself, I follow ReSharper's advice and always use var.

As for the question, I think explicit typing would be better practice. Especially if they're new to the language or programming in general, it gives the readability of the code a big boost.