I’m an all but retired programmer learning for fun. I used to prefix everything with the type or some abbreviation. Following the crowd. But quit the habit when finding I needed to write notes explaining the prefixes. Focussing on plain language descriptive names have been the thing since. And if I can’t think of a clean smelling name then it’s a clue I don’t understand what’s required. Var now looks like an extension of that, and the arguments against rather weak or very specific.

If you’re on VS, you can find out its type by hovering your mouse over it. Only when viewing the code on Github would you need to figure out the type. But then again, most reviewers only stare at the code on Github.

Indeed you are correct. What surprises me the most is that it’s gone this long without being noticed (or at least mentioned). I’ll take care of that, thanks!

1 is not a prime number

Customer customer = new();

It is short, you can read the type without moose hovering and it is consistent because it works for both class variables and method variables.

var doesn’t work for class variables.

Agreed!!! I’ve been programming since the early 90’s. I’ve had to come on projects and learn their coding behaviors.
It is bad enough having to understand explicitly declared variables that are not self-describing. Now you get this VAR variant and the same programmers will make it worse.

Many work environments didn’t have coding standards or peer reviews which didn’t help either.

I don’t use VAR.
And I do get sometimes it isn’t too bad with some self-describing variable names, but I prefer INT, STRING, etc…

I guess if I used it more, it may not be an issue, but too many new things you have to learn now and expected to know them all in and out for me to change.

Totally agree on this point. Hence I’d rather strongly type and appropriately name variables and use refactoring to rename a variable if needed. Have we forgotten refactoring??

“4. If you change the return value of a function, I want to know everywhere it was used. That var does not give you compile errors means you can miss things and get unexpected behaviour, particularly when marshalling for interop code.”

Makes sense to use var when type is clear or inferred. isActive can be inferred that it is boolean and not confusing. However, a variable named Status doesn’t infer anything and using var Status can lead to the next developer spending time figuring out if Status is string, enum or an something else.

Thank you for reading my blog! I use var when it’s clear and obvious, which is usually the case in small sections of code such as loops and short methods. When in doubt, be clear and give the full declaration.

This works:
public static void Main()
{
long num = 17;
num = 9223372036854775800;
Console.WriteLine(num);
}

This does not:
public static void Main()
{
var num = 17;
num = 9223372036854775800;
Console.WriteLine(num);
}

It is because the compiler has assumed (because of the missing ‘L’) that the number will not be used as a long later.

Adding a type to the variable declaration has cleared up all ambiguity here. Specifying a type is always the clearest approach. As developers we should always make our code as clear as possible.

[This of-course is a very simple example, in practice the situation would be more complex.]

Thank you for your input. You mentioned TypeScript (which I also prefer to straight JavaScript). Just as with TypeScript, all C# variables are strictly typed (unless one uses object or dynamic). For instance, bool isActive = false; and var isActive = false; are functionally identical. Both are strictly typed. But of course, you are welcome to use or not use var however you like and however you feel is best for your team.

Also, another annoying aspect of var is when you are doing code reviews. Since you don’t have access to the IDE while comparing it can be hard to tell exactly what is going on if things aren’t explicitly typed.

There is only one instance when I use var, and that is for an anonymous type.

I totally understand old school. I come from a C background. Every C# feature has a place and a reason. Part of the beauty of the language is its flexibility. And you won’t find any flames here.

You are always free to use the explicit declaration if you prefer. But that wouldn’t help you know if it contains line items and such. If those potential line items aren’t referenced in your foreach loop then you probably don’t care, but more to the point, the query should not do any more work than necessary if you can control it.

On another note, you say you like to use .ToList() on your query. There are times this makes sense, such as to prevent multiple enumeration. However, consider the possibility that the table from which the active orders are retrieved may contain millions of rows. Doing .ToList() will attempt to read all of that into memory and would likely fail. I’m just saying to be aware of the size of the data set when using it. Processing without the list takes only what is necessary as you need it (possibly with some buffered rows to lessen database access, but not all of them).

var activeOrders = GetAllOrders().Where(o => o.Active);
foreach (var activeOrder in activeOrders) { … }

I tend to use the .ToList() function and explicitly declare the active orders, but I definitely would have declared the activeOrder in the for if I didn’t do the first.
I wonder if that is a:
* table structure of the order headers
* a specific query structure that only have the id, reference, debtor name and total value in it
* a structure that has the header and all line items in it
* a structure that has header, line items and discounts etc.
* a wrapper class that contains the previous mentioned structure but have some of the header variables as properties.

That is why I like to see an explicit type when something is declared. It just let me know which functions can use that as is, or how it will have to be wrapped to be used.

Thank you for your comment. This article is indeed my opinion; how I (and my team) like to write code. I don’t know that I’d call it “rules” as much as how we limit verbosity while maintaining clarity in our code. Of course you should do what you feel is best for your project and team.

Indeed you are correct, thank you. I have updated the article.

I appreciate your comment. To answer your question, I care because I prefer visual clarity, even if technically Visual Studio and the compiler will make sure var always works. We all have our preferences. Mine is as I describe here. But I also understand that others have different opinions, which is why I also referenced Michael Brennan’s article. I would assume you agree more with his reasons than mine and that’s okay with me.

Why do you care what type foo.GetBar() returns? We can see right in the code that bar can DoABarThing() without needing to explicitly state that bar is an IBar. I can count on zero fingers the number of times that an explicitly stated type was helpful for me in reading and understanding someone else’s code.

I stand corrected. Thank you DaTurk. An anonymous object does indeed require a var. For example, the following object could not be held in a variable without using var.


var anon = new
{
Name = "Enigo Montoya",
FavoriteNumber = 42
};


When declaring an Anonymous Object you have to use var …