geek yapping

Twitter












The slippery slope of "var"

The var keyword has been a rather controversial addition to the C# language.  Many developers initially fear it, getting lost in demos that use it.  Eventually, they come to understand it as something "lazy" programmers would use and often dismiss it.  I've gone through these stages.  I even remember my blood boiling when I saw resharper, out of the box, suggest to use it!  I never really understood it as anything more than implicit typing.

Recently, I decided that I should learn new concepts with new languages instead of just trying to learn and do examples in the same old.  Why not kill two birds with one stone!  I've been exploring a lot of interpreted languages (functional and imperative), focusing on Scheme (LISP) and python.  I've had a great joy reading and conceptualizing new things in these language.

Studying new concepts and applying them with dynamic languages has made me notice, more than ever, all the boiler plate type code to get anything done in C#.  After a weekend of hacking in python, I find myself skipping type declarations in C# only to get compiler errors :(.  The simplicity of
names = ('Bob', 'John')
in python is doubled in C# to
List<string> names = new List<string>{ "Bob", "John" };
without any added value!

I have been struggling to find ways to bring this simplicity to C#, short of switching to python altogether :).  My favorite way is to cut some of the crap and go with
var names = new List<string>{ "Bob", "John" };
.  No loss of information and some added clarity!  However, the use of var is often frowned upon as if it were unprofessional, my peers reading my latest code only to comment on my "abuse" of it!

What I was missing is the next step in the progression of understanding var. I was starting to realize that it adds clarity through readability!  No longer do I have to scan through a bunch of type verbiage in a variable declaration to find the name, let alone the content.  Readability alone wasn't convincing my critics so I pondered on the topic some more in regards to another set of concepts I have been working to grasp, DDD.

In studying DDD (Domain Driven Design) I detected a sense of deja vu.  The core concepts, of creating a ubiquitous language and model that permeates code, was resonating all the way down to the level of variables.  If a variable represents a list of employee names, it should be labeled employeeNames. If we cram that much intent and meaning into our variable names, why do we even care what primitive or compound type is used?

employeeNames might be implemented as a List<string> in C# or a simple list in python.  However, when all is said and done, employeeNames is neither a List<string> in C# nor a list in python.  Thinking about it as such adds no value, just translation overhead.  employeeNames is simply a variable to store employee names, it's type is employeeNames!  The name implies this directly.  It describes a kind of name, employee, and it's plural, clearly a collection or set of names.  The same would apply for a variable to represent age, even if implemented as an integer, it's not an integer, it is an age!

I think this is the answer to help convince people that using var is actually a good thing.  Especially when writing unit tests where readability is a primary concern.  I would even go so far as to suggest using it anywhere when declaring a variable.  The only argument I have heard against this, thus far, is that this will lead to ambiguity.  But wait a minute, I think the opposite is true!  Static typing leaves room for intention to be left in the type itself.  Because of this, developers get sloppy with variable names.  When developers don't have a type to prefix a variable, they typically put more intention into the name, for their own sanity!

I would be more inclined to believe I would run across
List<string> employees = new List<string>();
in C# than
employees = ('Bob', 'John')
in python.  This example requires knowledge that employees is implemented as a list of strings for someone to extrapolate that employees holds names and not ages or something else.  However, with a list of strings, this may just be a guess!  It could be a list of their emails or maybe home addresses!  I know I've seen this in the past and I know I've done it myself.  This added translation only decreases the maintainability of the code.

So the next evolution, in the slope of understanding and using var will be understanding it as a tool of readability and to help avoid leaving intention in types.  This adds a layer of linguistic abstraction that hides the implementation of our variable's type and makes it more flexible.

I think the last evolution with var, will be to help developers get more familiar with the ideas behind dynamic typing.  Implicit typing is like a step in the direction of dynamic typing.  The last thing to do, seems to be to drop the use of var at all.  It's simply linguistic boilerplate to developers (even if it serves a purpose to the C# evaluator).

So get your var on, don't be ashamed!

Feedback

# The slippery slope of "var"

The only thing I am going to say is you should at least have to declare your variables. Declarations provide insight into the scope of your variable and without them no one would be able to keep track of where things start and end (including the compiler, it would have to guess only making you more confused).
<br><br>
Now I am going to say more :). Static types are purely for the developers sanity and readability. Newer dynamic languages can do some pretty amazing things without the limitation of the types the CLR defines.
<br><br>
PS. VB lover ;) 9/24/2009 6:35 PM | James Timperley