To var or not to var...
Interesting thread on the ALT.NET mailing list, where Ilya is talking about some of the debate on the ReSharper 4 team surrounding the new var keyword, and the rules they ended up using for R# suggestions.
In my .NET 3.5 work so far I have tended to shy away from var, preferring to be explicit about my type declarations. I even turned off R#'s suggestions to use var instead of an explicit type. After reading Ilya's messages on the thread, I am reconsidering the issue, especially now I understand the logic behind when R# suggests var.
One of the conditions is when the right hand side of an initialisation explicitly shows the type. For example:
Dictionary<A,B> dict = new Dictionary<A,B>(); /* OR */ var dict = new Dictionary<A,B>();
In this case, why all the additional typing? We are already specifying what type we want, why duplicate it on the left and right sides of the expression? Both expressions are equivalent, we are just leaving the compiler to work out the obvious bits.
I'm beginning to think eliminating this duplication is a good thing. It removes a bit of noise from the code and let's you focus on the important stuff, without losing any type safety.
Obviously care needs to be taken not to abuse this feature, but for simple cases where the type is immediately obvious from the code then I'm starting to think var might be the way to go.
Update 2008-03-05: Ilya has posted some more arguments in favour of using var on his blog.
3 comments:
Nice thought,
Probably for readibility we might still need to define the type on the left hand side as in some cases the right hand side may be a function returning the instance.
I have to wait and see, might be after sometime we will be used to inferring the type ourselves while reading.
I'm struggling with the same issue. While I understand removing the duplication of the explicit declaration in favor of the var keyword, I'm still not certain how I feel about the var keyword being used to define the return value from a method.
If the method return values are changed and returns something different, you don't have to go back and change the variable as well.
But is that really more readable?
Thanks for the great comments Hassan and Brian. I agree with you both about being uncertain with the value being initialised from a function call. In this case I'd probably err on the side of being explicit (at least until/if we all get used to inferring the type as Hassan mentioned).
This conservative approach is being used for ReSharper 4.0, which only suggests replacing a declaration with var if the right hand side explicitly lists the type.
@Brian, I also like your point about not having to change the type of the variable if the return value from the function changes. I've been thinking about that too -- it enables you to have pseudo duck typing (a la dynamic languages), without actually giving up the advantages of static typing.
For example, if our code has:
var duck = GetQuacker();
duck.Quack();
then the code will still compile if GetQuacker() returns any object that Quack()s.
Will it cut down on maintenance effort, or will it make it more confusing to read? Can we learn to infer the type from the method name and context as quickly as explicitly listing the type? I'm not sure, but I'm going to try keep and open mind and consider each case on it merits. Not much point in doing something purely because that's how we've always done it :-)
Post a Comment