Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

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?


migration rejected from Jan 16 at 16:13

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as primarily opinion-based by gnat, GlenH7, Thomas Owens Jan 16 at 16:13

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

4 Answers 4

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

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.

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

I do this by giving the method a good name. That way you won't need to change the name of every variable when refactoring the method. – David Harkness Dec 15 '11 at 8:40
So what happens when you decide that you using a stream for an image was the wrong approach and you change the Load method signature? (This may not apply in the specific case but it is certainly a generic problem.) – Murph Dec 15 '11 at 8:41
Well, as David says, picking a better name for the load method can fix it, "LoadImageStreamFromWidget". – Carra Dec 15 '11 at 8:50

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.


As I see it there are two aspects of using implicit typing. The first is, as Andrew Shepherd and the other answerers pointed out, to use the var keyword in a way that increases readability.

However, in my opinion there is also another neglected aspect, and that is to increase refactorability. Lets say you see this code:

foreach(var gear in machine.getGears())
  if (inspector.isLoose(gear.getScrew())

You realize that "gear.getScrew()" is called twice. To increase readability and performance, you may introduce a local variable this way:

foreach(var gear in machine.getGears())
  Screw screw = gear.getScrew();
  if (inspector.isLoose(screw)

This code is different from the previous in one more way, because here you explicitly state the type of gear.getScrew(). If someone later refactors this code, and changes the return type of gear.getScrew() (because e.g. a screw may be represented with a simple identifier), the he or she will certainly have to change the gear class and the inspector class. The original code snippet would remain unchanged (naturally), but the second one is needed to be changed in regard to the return type. I would prefer to write it this way:

foreach(var gear in machine.getGears())
  var screw = gear.getScrew();
  if (inspector.isLoose(screw)

This code snipet is agnostic to the return type of the gear.getScrew() method. (And indeed has nothing to do with it.)

My conclusion is, that to keep your code from becoming resistant to refactoring, you should use implicit typing in higher abstraction levels of your code, for variables that are only used to transfer objects between functions.

If you can easily write the code without even introducing the variable, it is sign that you should use implicit typing.

So to answer the original question, you should encourage your padawans to consider implicit typing. Especially if you also encourage them for clean coding, and to separate abstraction levels.

I wish there were a means of declaring that an identifier was being used to hold a "temporary" value, such that (1) writing to it other than by creating it would be forbidden, but (2) the name could be reused within the same block, provided that (3) every use of a name could ever be reached from any particular declaration without any other intervening declarations, could always be reached in such fashion. That's a very common use of var, but not the only one. – supercat Jan 15 at 17:04
This is an interesting idea. Can you name a language that implements this, or a similar approach? I know that what I described is not the only, and not even the primary usage of var, but as other usages where already well describen by others, I wrote about the one that was not yet pointed out :) – Gábor Angyal Jan 16 at 7:21

protected by gnat Jan 15 at 13:26

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.