When to use var in C#?

Question

In C#, local variables in the scope of a method can be declared with implicit type using var, and type is solved at compile time:

var i = 10; // implicitly typed
int i = 10; // explicitly typed

^{Example of MSDN}

Cases of use of anonymous types even require the var, as already mentioned in a reply here from the site. But in cases where it is optional, is the choice purely a matter of style? There are recommendations (official or otherwise, provided that they are justified) to use or avoid the var in certain situations?

Answer 1

There are situations where one of the two forms is "required" and others which, anticipating the long answer, is a matter of taste.

And just to make it clear that we are talking about local variables, not structure fields that should always have their explicit types (as well as parameters). There is debate whether this should change or not. There are difficulties in deploying.

LINQ

When the LINQ is being used it is common to select some information fields as is done in SQL and the return of the information will be encapsulated in a structure which was not defined anywhere, it is created there at the time of the select. What is her type? Nobody knows. But since all C# data needs to have a type, we can call it anonymous type. And an anonymous type cannot be stated explicitly, so the only alternative is the use of var.

var dadosProduto = from p in produtos select new { p.Nome, p.Preco };

In this example the variable dadosProduto will have a type IEnumerable<AlgumTipoGeradoNaHora>. This type will only have two fields with (internal) names that only the compiler knows.

Contrary to what some imagine, the var It’s not that mandatory, so for purists, the choice should be never to use it. It is possible to explicitly create before the type needed to accommodate the result of select and use this type in the query. It is very long and no one wants to do that.

But the var is that, just a convenience, not an obligation.

Polymorphism

There is a case where using the type explicitly is mandatory, at least to pass the correct intention. If you want to create a specific object of a specialized type, but want the variable containing it to be of a more general type, it is obvious that declaring the type explicitly becomes necessary:

Control botao = new Button();

In this case the variable botao be the type Control but it will hold an object of the type Button which is obviously derived from Control.

You can still avoid using one cast, but it is a worse and not recommended solution.

Ambiguity

You can’t use the var when it does not initialize the variable.

var produtos; //não funciona

How to know which type is the variable? There is no information indicating this, neither the programmer nor the compiler know. Without knowing the exact type it is only possible to declare a variable with another keyword that allows the check to be done in Runtime (but there is another matter and a form not equivalent to what was asked):

dynamic variavel;

It would even be possible for the compiler to infer the type by its later use, but they did not want to complicate the compiler for something that may be debatable. Functional languages often search all code to find the type. Great. But if the poor programmer wants to know the type, he will have to do the same (of course Ides help a little). Then it seems wiser to have to make it explicit in the place of the statement if it cannot be determined right there.

Liking

Otherwise there are controversies when using the implicit or explicit statement, even among C# team members there are disagreements.

Some say that the var it should only be used in cases where there is no other way or where it would be too big to make a code that exempted it, that is, only in the example cited above.

Obviousness

Others, perhaps most, already think that the var should be used in any situation where the type is obvious and visibly identifiable. Maybe it is even the most sensible way (is my :P). Examples:

var x = 1;
var texto = "exemplo";
var botao = new Button();
var lista = new List<cliente>{ cli1, cli2 };
var dic = new Dictionary<string, Tuple<Produto, Fornecedor>>();

In all these cases the type is very explicit right next to the variable name. There is no need to duplicate this text on the other side. You’re crazy to write something like that, right?

Dictionary<string, Tuple<Produto, Fornecedor>> dic = new Dictionary<string, Tuple<Produto, Fornecedor>>();

See? You can’t even read part of the code that is perhaps more relevant. And when you have to break too much line indicates something wrong in the code.

Controversy

The most controversial case, and it has supporters, is to make explicit when the type is not obvious.

var valor = CalculaParcelas(total);

What kind is valor? int? float? double? Strange to use these guys, but it could be. Decimal seems more logical but could be bool, the method could throw the value elsewhere and only say if it went all right, another strange thing, but it could be. It could be a struct or class any defined by the program. Explicitly it is clearer what you will have to deal with:

List<Decimal> valor = CalculaParcelas(total);

It makes sense that you have plots with different values by some criteria and that each individual value needs to be known, but you couldn’t know by looking at the code.

Visual Studio can give you a hint. And let’s face it, C# wasn’t designed to be programmed without an IDE (although it’s perfectly feasible with no loss except a little bit of productivity, which will make relatively little difference). Still it’s fair to think it should be visible without having to press anything or move the mouse.

But anyway if the variable usage is far from the statement, you will prefer to use this VS feature instead of looking for what is explicit in the code.

With the right tool (Resharper which clearly encourages the use of var) it would be possible to use the var initially to facilitate and with one or two clicks or keys change to the explicit type taken from the method signature. This will only save typing which is not the best reason for using the var. But visual pollution with redundant information is a good reason.

The var may be the best expressiveness solution

It is also true that in many cases the type of the variable matters little. And in some cases not knowing the type may be useful. Remember when they told you not to use hungarian notation? I know it’s not the same but the principle is the same. Don’t link the type to the variable explicit in the code. Of course this can bring bugs subtle in some cases.

Isn’t the name of the variable or method that should represent its function in the code? So why is the type so important? Without the type written in the code it is easier to maintain in several situations.

So let’s do it this way:

var parcelas = ObterListaParcelas(total);

It’s a lot clearer, and without being explicit about the guy, right? In addition to the variable name show that will be plots the method clearly says that comes a list of plots. Of course it is not yet certain that is a List, so little of Decimal. But if the team is organized and follow patterns you can even infer this with some certainty. It’s not perfect but it’s almost obvious.

Evidently the final solution would not be to force all methods to carry their type using Hungarian notation, thus:

var parcelas = PegaParcelasListDecimal(total); //muito feio e possivelmente problemático

More controversy

But using more representative names leaves us in an even more controversial case:

var listaClientes = PegaListaClientes();

It is similar to what I quoted in the previous section. It is easy to imagine what kind of lista will be List<Cliente>, especially if it is a software developed with rigid patterns of nomenclature and style than use. And you can also easily identify what the tool-less type is. Of course the method could have been developed by someone clueless and return a different type than the name indicates, or who knows even have a reason for it, but it is not the normal.

But yes, you have to imagine, it’s not guaranteed. The fear of difficulty of identification makes some sense to programmers of static languages. Those who program in dynamic languages find it very normal not to have the type and good programmers are not doing worse software and less productivity because of this.

Choosing a criterion

Of course it becomes more difficult to determine when to use or not in these cases, the evaluation will fall into subjectivity. A criterion of using the var when the type is already concretely explicit in the statement is more objective and easier to follow. Another objective criterion is never to be explicit, although radical, has adherents.

The more I use the var And I have no difficulty, but I want to get close to it. So the mileage of each one can vary in cases like this. Of course, if you are going to expose the code to an outside audience some will be annoyed by not having a type declared explicitly. A probably smaller number will be annoyed to have the guys polluting the code. It is not enough to please everyone. But this is another criterion to take into account beyond taste.

Completion

There are no official recommendations. After trying, they realized that it would be a mistake to make that determination. The advice is general: whenever it’s possible to choose which form to use, use what the team determines. Keep the pattern even if the team is just you.

More and more I see that I use it var becomes more prevalent in code C#. At least in obvious cases. It seems that people are learning that it is advantageous and is not accompanied by problems.

Curiously people use values without knowing the guy all the time. Every time she uses a method or even an operator in an expression, she often does not know for sure what the type of the result of that sub-expression will be. She doesn’t make a cast explicit for the same type that will give the result, just to make explicit. Why the implied statement should cause more problems than this?

Nobody cares about the guy who comes back here, it just works:

ImprimeListaQualquer(PegaListaClientes());

Documentation

Declaring the type explicitly should only be used when the programmer wants that type to be always used. That a change in initialization by a change in the method that results in the initial value does not change the type. Writing code is documenting something. Putting the type explicitly is saying that it needs to be of that kind, no matter what. How do you document that the type is not important? Not putting it implicitly.

When I see code from a programmer, one of the many criteria to evaluate it is the use of var. Almost always those who do not use at least in obvious cases, or the person is unaware of the resource or has attachment to useless rules, which says a lot about their qualification. Of course it cannot be the sole criterion and one must take into account the context, for example if it is not legacy code, after all the var there is "only" since 2007, or if it does by "imposition" of the team.

References (opinions):

• In the OS here and here.
• In the Software Engineering.
• In the Infoq.
• In the blog of who implemented the resource in the language. Perhaps the closest to an "official recommendation".
• Blog that indicates there are differences between official documents.
• Authority under C++ on the auto (equivalent of var).

Extra

C# 9 has a new Feature that can do the var be much less used.

Answer 2

I believe that this is much more a matter of legality than anything else. When I read about this I found discussions on the topic, and the recommendations will depend on what the person thinks of this topic.

I believe that using var makes the code more readable. If I have an Order class that has Products and I want to put this in a variable, I would do so:

var pedidos = cliente.Pedidos;

I don’t care if requests are a List, an Immutablelist or Ienumerable, I probably just want to iterate on it. But if we do so:

ImmutableList<Pedido> pedidos = cliente.Pedidos;

To me, we’re adding unnecessary information. Some argue that var does not facilitate readability when assigning a value returned from a method to the variable. Something like:

var pedidos = ObterPedidos();

But it still makes no difference to me - I still know I’m dealing with requests. Whoever uses this argument usually gives a stupid method name (like CalcularValores) and says that you do not have the information you need when using var in this situation - but for me, then the problem is another ;)

Finally, var brings another great advantage, if you want to change the return type of the method and not use var, you will have to change the statement everywhere it is called, which is not necessary to do when employing var.

Answer 3

At the beginning, the documentation of the Microsoft included a note saying that excessive use of var when not needed could impair the readability of the code. Then Microsoft removed this paragraph.

Short answers to your questions are:

in cases where it is optional, the choice is purely a matter of style?

Yes, is purely a matter of style since technically there are no gains or losses - the type of the variable will be defined at compile time as much as if it had been explicitly stated.

There are recommendations (official or not, as long as justified) to use or avoid the var in certain situations?

There are unofficial recommendations, however justified only by opinions, always debatable, which brings us to the answer of the first question: it’s a matter of style.

When to use var in C#?

You are required to use the var as in the case you mentioned and may not use it in some other cases, listed in official documentation.

In other cases, it is a matter of style.

Commentary:

C#, although statically typed by nature, it was born less verbiage than the Java, for example, and already allows dynamic typing and already has several elements of functional languages. The keyword var was a great hit, allows an even cleaner code and leads us towards a more expressive code as well - we can exchange the artifice of explaining the type of variable by the practice of giving meaningful names to our artifacts.

So, although this will always be a matter of style, the style that will predominate as recommended will be to use var where permitted by language - decision-making process: "if the compiler allows, then use".