Introduction

It has been quite a long time since var was introduced, yet it stands debatable among .net developers. Everyone has a different understanding as and when to use var as a type. A couple of days ago I was also a part of one such discussion, and so I decided to share my understanding.

 

Readability

Every developer has all the right to use var as and when they like, it’s just a matter of one’s choice. However, I think, sometimes it’s good to use the actual types rather than var.

 

Well, the above code written with either of the approaches will work just fine. But if you ask me to choose, I would always prefer the second one. Why? Because the code itself tells me that radius is an integer and text is a string. Now some would argue that even the first one does the same. I do agree, but as I mentioned it’s just a matter of choice.

One of the many reasons why Microsoft introduced var is to make the code more readable and thus helps a developer writing a clean code. For example, see the code below.

 

In the above code we initialized a variable with an object using implicit type casting. It makes sense because the new keyword tells the reader that the variable is an object reference. Though the two statements do things differently, so it’s actually not a fair comparison. However, using var instead of an actual type in the above code, makes it more readable, clean and thus maintainable.

I think using a var is fine until and unless it does not hamper the meaning of the code. The reader shall be able to derive the semantics (what it does) of the code while looking at it, as in our code statement creating a new dictionary is equally understandable as the above. Rather in the above statement the type declaration serves as a distraction.

 

Maintainability

Assume a method CalculateTotalAmount, that uses an integer array amounts, and the value at index 2 is being used to initialize a variable transactionAmount. The variable is then passed as parameter to another method CalculateVAT. Notice, that the type of parameter that our method CalculateVAT expects is an integer. And that while writing this code the developer is certain about the type of transactionAmount being an integer. Therefore, he decides to use var as a type and not int.

 

Think of a situation where after six months or so the same developer comes back to modify the code as per the new business logic. Now, if I were that developer, the first question that I would have asked is that what is the type of transactionAmount? To figure that out I would have to check the type of the array, amounts. I would also have to verify the parameter type for the method CalculateVAT, and proceed accordingly.

This whole problem could have been solved, if the developer would have used int as a type instead of var while declaring the variable transactionAmount, in the first place. That would have made three things clear in an instant,

  • transactionAmount is an integer
  • the type of array amounts is an integer
  • the parameter expected by the method CalculateVAT is an integer

However, there can be one other scenario in which we change the type of amounts and type of parameter that CalculateVAT expects, to decimal. If the code is written as is, it would work just fine because we are using implicit type casting. But if we would have used an explicit type casting, declaring the variable as int, we would have been in trouble. We might face some exceptions and we definitely will have some data loss. Using a var saves us in such situations.

When we use an anonymous type to initialize a variable, we declare the variable as an implicitly typed local variable by using var. The type name cannot be specified in the variable declaration because only the compiler has access to the underlying name of the anonymous type.

Also, using var is helpful while working with LINQ Expressions. It helps in scenarios when we (especially new developers) are not certain about the results that an expression would return.

 

Anonymous Types and LINQ

One of the main reasons for introducing var was to provide an ease of development while working with Anonymous Types and LINQ. And often these two are used in conjunction. Let’s see it in code:

 

  • Line 1 – we are grouping the _paymentList elements based on anonymous object.
  • Line 2 – we are now selecting each element and creating a new anonymous object using its properties.
  • Line 4 – we are now returning the collection of these new anonymous objects as a List.
If we wish to use explicit typing here, we need to create a new class and then use it instead of var. But what if the required object properties are changed and we need to return more/less data? Do we create a new class or our update the existing one? Well, the best alternative is to use anonymous type.

Since we are creating our object on the fly we cannot use static typing here. And, that’s when varcomes to our rescue. We declare the variable as an implicitly typed local variable by using var. The type name cannot be specified in the variable declaration because only the compiler has access to the underlying name of the anonymous type.

Summary

At this point I would highly recommend Uses and misuses of implicit typing, a very well explained article by Eric Lippert.

  • Use var when you are using anonymous types.
  • Use var when the type of the declaration is obvious from the initializer, especially if it is an object creation. This eliminates redundancy.
  • Consider using var if the code emphasizes the semantic “business purpose” of the variable and downplays the “mechanical” details of its storage.
  • Use explicit types if doing so is necessary for the code to be correctly understood and maintained.
  • Use descriptive variable names regardless of whether you use “var”.
  • Variable names should represent the semantics of the variable, not details of its storage. For instance transactionAmount makes more sense to a reader than decimalAmount.

 

Undoubtedly it’s an individual’s choice when to use var. However, through this post I just shared my opinion about the same. It would be great to receive any feedback on this topic. Please do share your opinion through comments.

Categories: .Net Core

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.