I'm looking at the upcoming Visual Studio 2017.

Under the section titled Boosted Productivity there is an image of Visual Studio being used to replace all occurrences of var with the explicit type.

boosted productivity VS2017

The code apparently has several problems that Visual Studio has identified as 'needs fixing'.

I wanted to double-check my understanding of the use of var in C# so I read an article from 2011 by Eric Lippert called Uses and misuses of implicit typing.

Eric says:

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

I think most of the var usage in the code is probably ok. I think it would be ok to not use var for the bit that reads ...

var tweetReady = workouts [ ... ]

... because maybe it's not 100% immediate what type it is but even then I know pretty quickly that it's a boolean.

The var usage for this part ...

var listOfTweets = new List<string>();

... looks to me exactly like good usage of var because I think it's redundant to do the following:

List<string> listOfTweets = new List<string>();

Although based on what Eric says the variable should probably be tweets rather than listOfTweets.

What would be the reason for changing the all of the var use here? Is there something wrong with this code that I'm missing?

  • The code in the screenshot is exactly the sort of thing you agree should not use var... Clarification?
    – Telastyn
    Commented Jan 3, 2017 at 1:37
  • 1
    I think that all uses of var here are fine. You could possibly change one - but even then I think it isn't really necessary. Why change them all to explicit type? Commented Jan 3, 2017 at 1:44
  • 2
    Keep in mind that what is obvious to humans isn't always obvious to visual studio. Commented Jan 3, 2017 at 2:05
  • All? You have one error in the screenshot that is clearly var related.
    – Telastyn
    Commented Jan 3, 2017 at 2:36
  • Well it's not an error as such but rather a warning of the sort you'd expect a linter to point out. According to the image, all of the vars have been marked in the same way; with the same cautionary cross mark next to them and a red underline. Presumably Visual Studio wants to correct them all in the same way. Unless I am mistaken. Commented Jan 3, 2017 at 2:40

2 Answers 2


TL;DR: no, Microsoft are not discouraging the use of 'var' in C#. The image is simply lacking context to explain why it's complaining.

If you install VS2017 RC and open up the Options panel and go to Text Editor -> C#, you'll see a new section: Code Style. This is similar to what ReSharper has offered for a while: a set of configurable rules for coding styles.

It includes three options around the use of var: for build-in types, when the variable type is apparent and "Elsewhere". In each case, you can specify "prefer explicit type" or "prefer var" and set the notification level to "none", "suggestion", "warning" or "error":

enter image description here

  • 9
    What is the default? If the "factory setting" is "Prefer explicit type" then it could be argued MS is discouraging the use of var.
    – JacquesB
    Commented Jan 3, 2017 at 10:40
  • @JacquesB, the defaults are as shown in the screen shot. As all are set to "None", it's difficult to know whether "Prefer explicit type" is actively set as MS's preferred way, or whether that's just the "zero value". As far as I'm concerned, the best devs all favour var, so I don't much care what MS's views are on this matter.
    – David Arno
    Commented Jan 3, 2017 at 10:50

I think you are reading too much into it. So, there is a feature that allows you to replace usages of implicit typing with explicit type annotations, and you conclude from that, that implicit typing is discouraged. There is also a feature to compile C♯ to CIL bytecode, would you conclude from that that C♯ is discouraged and we should all write CIL bytecode instead? Probably not.

Microsoft is simply showing off the deep understanding the IDE has of your code. It can even write your types for you without you having to spell them out. That's it.

This is simply a good example of showing off the IDE's code comprehension capabilities. It is small and self-contained (unlike showing a larger refactoring), it is available in all editions and applicable to all developers (unlike some of the admittedly very impressive architectural visualization features that are only available in Ultimate and not applicable to a significant portion of VS's potential users who will never have projects that large), and although it is very simple (it is literally doing the exact same thing csc.exe has been doing ever since var was introduced), it certainly looks impressive, especially to someone who doesn't really understand implicit typing and type inference (or who tries to google "type inference" and gets overwhelmed with terms like Hindley-Milner, unification, backtracking, when in fact C♯'s local-only inference is extremely simple and straightforward).

So, in short: it's a flashy way of showing off an IDE feature.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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