Using ‘var’ in C# — a pragmatic approach
Who would have thought that a simple keyword like ‘var’ would cause so much contention in development teams?
Let’s dig into ‘var’, and see what’s going on, and what we can do about it.
Firstly, what is ‘var’?
‘Var’ is a keyword that you can use in C# instead of a type name. It was introduced way back in C# 3, and you can read the official documentation about it. Really, it usually comes down to something this:
In this case, instead of repeating the name of the class, you can use ‘var’. Sounds simple, right?
‘Var’ can be used whenever you’re instantiating a variable, including when calling a method. Like this:
It makes sense, especially if your type name is pretty long, or you’re using generics. For example, using ‘var’ can dramatically cut down the length of some of your lines. Say you have to deal with a list of KeyValuePair objects, and you want to do a grouping on them. Your options would look like this:
So in this case, using ‘var’ really reduces the number of characters on your line.
There are other uses of ‘var’ which I’m not going to cover here, because sometimes you can use ‘var’ to accomplish something that you otherwise wouldn’t be able to do (like when you’re using anonymous types), but rather I’ll focus on those cases where using ‘var’ is purely a coding style preference, and can be easily interchanged with the type name without any functional changes.
Now, from my experience, there are 2 main arguments I’ve heard when talking about ‘var’ in this way:
- ‘Var’ is amazing, and you should use it everywhere! Why are you wasting all that space and characters with type names?
- ‘Var’ is evil, it makes your code completely unreadable, and shouldn’t be used anywhere!
And I’ve seen teams spend a lot of time debating these two views to try and get a consensus. And here’s the thing — there is no right or wrong answer. But it’s worth digging a little deeper into why some developers prefer one way or the other.
The main point of contention usually comes down to readability. How does one way or the other help others read and understand your code?
By using ‘var’ you can replace long type names with just 3 characters, making the horizontal width of the line much smaller. However, it may now not be immediately obvious what the type is, especially if the variable is coming from the result of a method elsewhere.
Personally, I think it’s this last point that people struggle with when dealing with ‘var’, and it’s a genuine issue, even though it can be mitigated a lot of the time.
If you’re in an IDE (like Visual Studio 2022), your editor will give you all the details of your variables that you need. So if you do have something defined as ‘var’, just hover over it, and the IDE will tell you what it is:
Now that’s fine when you’re in an IDE, but what about when you’re doing a code review in something like Azure DevOps, or GitHub? There, you’ll only get the code, without any context. Or what happens if you’re doing some pair programming, and you’re the developer without the keyboard/mouse — just by looking at the code, you might not know what the type is that you’re dealing with.
Fortunately, this is a very common situation, and there’s a coding style set up to deal with it. You can use ‘var’ when the type is ‘apparent’, such as when you’re instantiating the type in the same line, and you’ve already got the type name there. Like this:
However, if the type isn’t ‘apparent’, such as when it’s coming from a method, you include the type name so it’s immediately obvious what it is:
This, hopefully, is a good middle-ground for those teams that are struggling to settle on an approach to using ‘var’. It avoids having to duplicate the type name unnecessarily, and also keeps the readability of the code, even if you’re viewing the code without any IntelliSense/IDE prompts.
If you’re using Visual Studio, you can configure your editor to use whichever style you want (along with really helpful tools to refactor existing code to match it), and for this type, it’s called ‘csharp_style_var_when_type_is_apparent’. All the details for this are on the Code Analysis page for this rule. There are other options there too, with examples on how each work.
As an aside, Visual Studio (and the other main IDEs) are excellent at helping you with coding styles like this. With the ability to easily configure the rule, and to apply that rule to your line/file/project/entire solution, you can simply change the configuration and apply it wherever you want. In fact, if you’re still undecided, try changing this configuration and just applying it to some of your existing code, and just see how it feels. Sometimes you have to see things like this in relation to the code you’re dealing with day-to-day to get a real feel for how it is to work with.
So if you or your team are struggling to come to an agreement on how to use ‘var’, I’d suggest trying out these options, and see if that works for you.
At the end of the day, these coding styles are there for your benefit, so go with what makes your specific team and project most productive. Remember that you’re also really easily able to change and refactor your existing code, so if you find that the style you’ve originally picked isn’t working for you, then go ahead and use Visual Studio (or whatever your IDE is) to refactor your solution for you in just a few clicks.
Personally, I was quite against ‘var’ when it first came out, because I wasn’t willing to sacrifice readability during code reviews, which was something I was doing quite a lot of at the time. However, over time, I’ve come to love ‘var’, and this middle-ground of only using ‘var’ when the type is apparent is the exact sweet spot for how I and my teams work.
Just remember to make sure everyone is using the same style across any particular solution. To a certain extent, it doesn’t matter which option you go with, but having a consistent style is a really good thing, and avoids code churn when different developers keep changing how things should be done.
