{"id":1008,"date":"2021-01-11T01:41:54","date_gmt":"2021-01-11T06:41:54","guid":{"rendered":"https:\/\/badecho.com\/?p=1008"},"modified":"2021-02-18T17:54:38","modified_gmt":"2021-02-18T22:54:38","slug":"when-to-use-var","status":"publish","type":"post","link":"https:\/\/badecho.com\/index.php\/2021\/01\/11\/when-to-use-var\/","title":{"rendered":"Readability Nightmare: When and When Not to Use var"},"content":{"rendered":"\n

var<\/em> : A Hotbed of Extremism<\/h2>\n\n\n\n

Life used to be simple, however with the release of C# 3.0, Microsoft ushered into the world<\/a> the birth of the implicit type keyword known as var<\/code>. With this keyword, we are able to make local variable declarations without having to specify the actual type of the variable. With var<\/code>, the compiler takes care of that nasty bit of business for us.<\/p>\n\n\n\n

Instead of having to write the following:<\/p>\n\n\n

\n\/\/ No var yet :(\nint number = 10;\nstring message = "Hello there";\n<\/pre>\n\n\n
We can now write it like so:<\/p>\n\n\n
\n\/\/ Hooray we have var! :)\nvar number = 10;\nvar message = "Hello there";\n<\/pre>\n\n\n
A good software developer will seek to reduce the redundancy in the things that they do; a proper engineer seeks to to optimize processes and increase efficiency. It’s only natural that many developers saw this new feature and recognized the boost in productivity it could offer in relation to writing code.<\/p>\n\n\n\n
Declaring a local variable used to require the writer to know what exactly<\/em> they were declaring. Not only that, it required the writer to have to actually write it<\/em>. These things take time, so why bother with any of that when we can just simply declare all local variables as type var<\/code>? Why indeed. This was the question asked by many a developer, and from this question a new form of software development extremism was born: Thou Shalt Always Use “var”<\/em>.<\/p>\n\n\n\n
To a very casual informer, this may appear as just another case of some guy on the internet making a very large exaggeration of things. But it really isn’t, and belief in this extreme approach is widespread. If you Google the topic, you will probably find that most people posting on Stack Overflow<\/a> as well as writing their own articles subscribe to the pervasive use of var<\/code>.<\/p>\n\n\n\n
Most prominently, however, is the (enabled by default) inspection rule in ReSharper<\/a> that will yell at you if you even think<\/em> to declare a local variable using any type other than var<\/code>. The keyword var<\/code>, like every other feature in a programming language, is a tool that has its purpose. And, like any tool, there are times where it is sensible to use it, and many times where it is not. <\/p>\n\n\n\n
I will go over the problems var<\/code> causes, as well as when it should and shouldn’t be used in a bit<\/a>; but first, let’s take a look at some history and ask ourselves why var<\/code> even exists.<\/p>\n\n\n\n
The Origins and Purpose of var<\/em><\/h2>\n\n\n\n
Was var<\/code> added to the language because Microsoft suddenly adopted a hipster-ish attitude towards local variable types, uttering a collective PFFT<\/em> towards the plebian uses of int<\/code>, string<\/code>, and MyClass<\/code> local type declarations?<\/p>\n\n\n\n
Well don’t look at me. How am I supposed to be able to read their minds? Mind reading aside, we can<\/em> state definitely that the introduction of the var<\/code> keyword was necessitated by the introduction of another feature into C# 3.0: Anonymous Types<\/a>. With anonymous types, we are able to create types on the fly. Often we’ll create these types while in the middle of some sort of complicated LINQ query in order to aid in the filtering or projection of some sort of desired result. <\/p>\n\n\n\n
Here is a very simple example:<\/p>\n\n\n
\nvar coolNewType = new {Id = 12, Message = "Hey Buddy!"};\n\nint id = coolNewType.Id;\nstring message = coolNewType.Message;\n<\/pre>\n\n\n
So, what’s the type of coolNewType<\/code>? If you look under the covers during runtime, you’ll see that its type is actually <>f__AnonymousType0`2<\/code>. This is of course, hideous and cannot actually be expressed in our code, so we have<\/em> to use var<\/code> here. <\/p>\n\n\n\n
This is not the only<\/em> reason for the introduction of this keyword, but it is probably the primary<\/em> reason. Redundant type specifications in code is of course a very large annoyance, and is indeed another reason why var<\/code> was introduced into the language. At least, according to Eric Lippert, one of the big bois on the C# team at the time. Feel free to read more of his thoughts on the matter in his article “C# 3.0 is still statically typed, honest!<\/a>“<\/p>\n\n\n\n
But what’s actually redundantly obvious vs not is very<\/em> subjective, and something I hope to grant some clarity with this writing. But before we get to that, let’s get to proclaiming one of my very own dogmas.<\/p>\n\n\n\n
Ready?<\/p>\n\n\n\n
var<\/em> Makes Code Easier to Write, But Harder to Read<\/h2>\n\n\n\n
The var<\/code> keyword has a countless number of proselytizers that proclaim it increases code readability. But what does it mean for code to be easier to read? Does it simply refer to code being more pleasant to the eye and less “ugly”, or should it perhaps refer to the ease in which one might actually understand<\/em> what the code is doing? I suspect that these advocates are of the mind that it refers to the former, and like other extremists, their beliefs have been shaped by a world view so simplified that it is unrealistic.<\/p>\n\n\n\n
A few years ago, I didn’t have any strong opinions on the var<\/code> keyword. My initial opinion on the matter was that it was more of a negative than a positive since it essentially hides information from the reader. But, other than that thought, I didn’t see it as too much of a bad thing really.<\/p>\n\n\n\n
This all changed when I got a new job where the coding convention made rampant use of the var<\/code> keyword. The software that was worked on dealt with very complex engineering concerns, with a lot of math and classes that dealt with signal transformations and the like. And I can say, with real world experience on the matter under my belt, that learning how the code worked and what it did, was made way, way<\/em> more of a nightmare because of the use of the var<\/code> keyword.<\/p>\n\n\n\n
If you’re dealing with real world code, with real world business concerns, then you have a complex hierarchy of objects you have to deal with. This is unavoidable and anyone who pretends otherwise lives in an ivory tower, probably making their living by selling books peddled by the useless idiots barking their dogmatic truths.<\/p>\n\n\n\n
Because of the rampant use of the var<\/code> keyword I no longer could tell just by eyeballing the code exactly what types of data I was working with. I had<\/em> to either Ctrl+Click the properties (going to their definition), or hover over the variable. This is a failure<\/em> in code writing, and horrifically tedious to work with. I’ll admit, every time I was told to replace a declared variable type with var<\/code> during a code review, I died a little bit inside. <\/p>\n\n\n\n
Real world problems aside, I’ve recently noticed yet another shortcoming to the rampant use of var<\/code>, and it has to do with a somewhat new feature to the language we’re all still probably wrapping our heads around.<\/p>\n\n\n\n
Nullable Reference Types and var<\/em><\/h2>\n\n\n\n
With the release of C# 8.0, Microsoft has bequeathed unto us the nullable reference types<\/a> feature. I’ve just started using it myself in some of my own projects, so jury is still out on this one, but I am liking what I see so far. If you’re unfamiliar with the feature, go check out the link I just provided as Microsoft will be able to explain it better than I can.<\/p>\n\n\n\n
Working with this feature enabled can cause additional problems to pop up if you’re a heavy user of the var<\/code> keyword. With nullable references enabled, the two following statements become an important part of the code you’ll be writing:<\/p>\n\n\n\n