I’m a somewhat older dude. I lived through the 1990’s with Visual Basic, before .NET. In those days, VB was so casual and loose. Don’t feel like declaring variables? No problem! You want to declare a variable, but not be specific about the type? No problem – use Variant! Variant was a 12-byte type that would dynamically change to whatever you wanted it to be.
When .NET came out, it was very strict in comparison. C#, coming from the “curly brace languages” like Java and C++, was very explicit. This was good, but why? Two HUGE reasons:
- The compiler, your bodyguard – first, when you are explicit with defining what KIND of a variable you need, you are incidentally telling the compiler. Now that the compiler knows exactly what you are expecting, it can do a great job of enforcing that “rule” for you. So if you declare a DateTime, and try to put a String into it, the compiler can give you a compile-time error. This is ideal, because this is when you want to learn about a problem like that!
- Future developers, your enemy – when you are explicit with your typing, it is very clear to another developer what your intention was. In most software shops, people roll-off and roll-on to projects all the time. If I’m running that software shop, I don’t want it built on inferences and assumptions – you really should be explicit.
Which leads me to a statement I’ve been saying for years. It’s been my experience that:
“Assumptions are the root of most software bugs.” – Robert Seder
If you think about it, this seems to be true. If you don’t have argument validation: “I assumed they would pass in a valid value!”. If you use the first element of an array: “I assumed that the array would be populated!”, etc, etc, etc.
So, enter the “var” keyword which is new to .NET 3.5 and is really picking up steam with .NET 4.0 + VS2010. Why am I taking such issue with this, to the point where I’m taking the time to write a blog post about it? Well, because this is a pretty nasty step in a potentially bad direction.
First, there are going to be proponents that will say “It’s not like variant at all! Var is enforced by the compiler!”. Which is true. And if the compiler was the only thing I was worried about, then I probably wouldn’t care. Var does NOT address the issue of the portability or maintainability of the code. For example, right out of MSDN:
var expr = from c in customers where c.City == "London" select c;
So, what is the data type of “expr”? If you are experienced with Linq, then you may know off the top of your head. I’m still not that strong with it, so I’m going to say it’s like an IEnumerable<Customer> maybe? Let me hover over “expr” and see. It shows nothing. Ugh. The only way I can tell what the data type is at design-time is if I look at intellisense, and see all the IEnumerable “extension methods” – so I’m assuming it is IEnumerable<T>. So how is this helping? It’s not! So why NOT do it this way then?
IEnumerable<Customer> results =
from currentItem in customers
where currentItem.City == "London"
Linq is where things started, but now I’m seeing more and more samples of just lazy, pure-and-simple, developers using “var” instead of declaring the type. This is bad because as a profession, it seems like we’re taking a step backwards – after we’ve actually started to make some progress! People are starting to use one naming standard now, FxCop is almost a household word (in .NET homes), etc – but now this “var” fad doesn’t show any signs of stopping. Why is this?
Ii think there are two reasons:
- Developers are lazy – and I include myself here, I always want to find the easiest way to do something. In this case however, I would argue that “var” makes my life more complicated later, which is why I’m not a fan. In the short-term, many people see this as acceptable because “what’s the harm?”.
- Microsoft is not on your side – it’s not often when I speak ill of our development overlords, but in this case the cold fact is that Microsoft is a software company. They are in the business of selling software. If they “shortcut” some stuff to lower the barrier-to-entry for some developers, they are going to do it. With “var”, Microsoft could tout “but you should always do things the proper way!” out of the one side of their mouth, but they could also tell old VB developers: “I know, the transition from VB6 was brutal – but don’t worry, you have variant back! You don’t need to declare variables anymore – it’s back to easy-street!”. This is where it’s good for Microsoft, “good” for the developer, and bad for everyone else. This sort of code is going to be much more difficult to manage (read: cost more).
All my point is here, is that the implicit typing that comes with “var” can make your code less readable, and more difficult to manage. It’s a shortcut that makes the .NET languages more palatable and forgiving to more developers, so that there is a lower barrier-to-entry. But just because you can’t do something, doesn’t mean you should.
I’m apparently alone in my thinking about this, as everyone else just seems to take this in stride like it’s the new normal. So, I just got this off my chest in one blog post, and I’ll be quiet in my lone opposition!!