This isn’t an article about the
How is that Controversial?
Most people cop out say that the use of
var is simply a preference. This is because the compiler figures out the type of the variable, and then compiles it just as if
var was never present. However, by always using
var, you will create more readable code, and find new insights to your code that you may not have noticed otherwise.
But, I Need to Know the Type
Take the following example:
Most people have no objection to this use of
var. This is because on the right hand side, the type of
thing is clearly shown.
But What if we were to receive the object from a function call?
Because the type of variable is not shown at the time of assignment, some feel that this is not a good use of the
var keyword. I have seen this in coding standards, and ReSharper even has a setting for it.1
But if you don’t use
var, you could be missing out on a small productivity enhancement. Suppose that in your code, you use your new object to do some work:
Later on, while refactoring, your
GetSomething function now returns
So long as
SomeOtherThing also has a
DoSomeWork method, you won’t have to change assignments where
var was used. This is a good thing - you have less code to change!
It’s Duck Typed!
Remember VBScript? Many moons ago, I spent the better part of a week tracking down an odd bug because a Variant variable was used in one way, but under some uncommon condition, it got reset to a totally different type. This was in a classic ASP web page that was a couple thousand lines long (you remember those, don’t you?). So I totally understand when people go into survival mode when they think their types are being diluted.
But it’s time to change that thinking.2
var isn’t duck typing. With duck-typing the existence of a method on an object is tested at run time.
var uses type inference, which means that the compiler figures out the type while you are coding. To say it another way, when you use
var, your code is statically typed. Every time.
But, I Need to Know the Type!!
You do! But it doesn’t need to be smacking you in the face! This is why I like F#. I’ll admit: it took a little getting used to; but not having types right in my face is not only pleasant, it’s a benefit. With type information in the back seat, the purpose of the functions I write are clearer.
In Chapter 3 of Uncle Bob’s Clean Code, he writes that functions should do one thing. He also goes through some techniques for focusing on what that one thing is. If you are successful at writing functions that do one thing, you tend to have very small, focused functions. This focus helps us come up with good names for our functions, and for the data that those functions work on.
What Does That Have to do With Types?
Have you ever written code like this?
Each of these variables is a string, but each has different rules associated with them. Are they required? How do I validate that they are formatted properly? Can I send an e-mail with the phone number? Why not? E-mail and phone number are both represented as strings!
In this case, the type system does nothing to help separate the concepts of a name, e-mail addresss, or phone number. You will have different requirements for each, and your program has to account for that. When we work like this, we use the name of the variable to tell us how to treat the data, not the type!3
Remove The Fear
Knowing the type isn’t as important as understanding the concept that the variable represents in the given context. Get those types out of the way, and have good names that reflect both the data (the type and variables of that type) and what is happening to that data (the functions). You can take a step in this direction by always using
var. Try it. I’ll bet your understanding of the code won’t suffer like you fear it will.
- Search for “var”, and find the setting: “Use ‘var’ only when initializer has type usage”. [return]
- Maybe even embrace immutability… [return]
- A topic for another day will be how to create types for representing these primitives - leveraging the type system, and creating more readable, maintainable, and correct code in the process. [return]