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):
Extra
C# 9 has a new Feature that can do the var
be much less used.
I would say use at all times, unless there is a good reason otherwise, but it is only my opinion. As I commented on a another answer, I see the type statement as a meta-given, useful in some cases but generally unnecessary (the variables should ideally be self-explanatory - both by the name chosen, and by the context). Otherwise, I don’t have enough C# experience for a well-founded answer.
– mgibsonbr
For the current answers, at all times It’s a bit of an exaggeration, but it’s very close to that. It’s funny that I thought it was the other way around. As I mostly use dynamic languages, I thought static typing languages virtually required explicit typing,#.
– bfavaretto
Whenever possible (if it is possible to infer it is possible to use var). Except for specific cases: You need a car reference, but the assigned object is pickup.
– user178974