VAR To Keep It Simple

Among various things in C# 3.0, one of the syntactical sweets that I find quiet useful is the 'var' keyword. Combined with R# intelligence, you create a very readable code that is not cluttered with excessive type reminders. Just enough to keep it strongly typed and readable.

Personally, I favor:

var people = new Dictionary<string, IPerson>();

over:

Dictionary<string, IPerson> people = new Dictionary<string, IPerson>();

15 Comments

  • I would have prefered:

    Dictionary people = new ();

    Would have made more sense when it's
    Dictionary people = new { FirstName="Foo", LastName="Bar" };

    I'd like to keep the types on the left edge which is easier when you are scanning through some lines of code.

  • @Sameera,
    in many cases, like this, a poorly named variable names does require to see the type. A better naming would probably eliminate that need, espacialy when scanning code. Then you would for sure see the type. collection initialization - good if you have the values and their amount is relatively low. Otherwise I would generate a method that it's result is assigned to the variable - just to keep it simple and readable. Besides, as I stated, if you work with R#, it is natural to say "I want a new collection of type X" by writing new Dictionary(), and after that worry about where it is stored (so be default it is var).

    After all, it's a matter of personal preferences.
    I recommend reading a post from R# team member, Ilya Ryzhenkov on this: http://resharper.blogspot.com/2008/03/varification-using-implicitly-typed.html

    Sean

  • When using R# you can get away with using "var" to declare the fields, but 95% of the developers don't use R#. So I rather see "var" as a pain in the ass, then a good thing. Simply because I need to read more stuff to find out what type the variable is..
    Eg:
    var people = new Dictionary();

    That's indeed pretty readable, you almost automatically also read the whole line, so you'll immediatly now that it's a dictionary.

    But:
    var people;
    // 10 lines of code
    people = new Dictionary();

    That's a pain in the ass and I'll bet you that within a few months you'll see applications popping up only written in vars which are totally unreadable with enhanced intellisense/coloring schemes (as in R#).

  • @JV,
    Why would you split those two lines and have extra 10 lines of code in between, to me that indicates a poor coding.

    Sean

  • @JV,

    off the topic, but I would recommend for that 95% of developers to get themselves R#, or an equivalent tool. It is more than a cool toy, it is something that allows you to lift yourself from trivial tasks to things that are more serious. Just a friendly recommendation.

  • @JV,
    your example wouldn't compile, it would have to be:

    Dictionary people;

    // 10 lines of code

    people = new Dictionary();

    "var" variables are not dynamically typed, they are statically typed through type inference, and the compiler must know the type where the declaration is made; so it's not a problem.

  • I'm reserving judgment on this one...my gut is that it will lead to less readable code...and it's not being used for it's intended purpose (to facilitate LINQ results). IMHO when you use a language feature for something other than it's intended purpose it will only end in tears.

  • @Rayan,

    allow me to disagree with what you stated. Yes, the origins of var raised from the LINQ project, but if you read the documentation, you will see this is not the only intent for the keyword (IMO it would overwise be restricted solely to LINQ expressions).

    The definition of C# 3.0 says "These new language constructs are useful individually in various contexts, and collectively for doing Language-Integrated Query (LINQ)."
    http://msdn.microsoft.com/en-us/library/bb383815.aspx
    Where var is filed under "Implicitly Typed Local Variables and Arrays" and "Anonymous Types" as well.

  • Sean, I fully agree with you on both the bad coding as the R# part. However we don't live in a perfect world and the sample I posted is, sadly enough, reality in lots of applications. So I still keep my concernes about it. You don't have to convince me about R#, R# did that itself some years ago ;)

  • One up for JV !! I wish R# would stop pushing vars by default.

    If you type "MyType myv = new " after this the intellisense would type the rest for you, so there's really not that much more to type, and I can immediately look at myv and tell the type. But what if I do this:

    MyBaseType m1 = factory.BuildType1();
    MyBaseType m2 = factory.BuildType2();

    now the "var" equivalent:

    var m1 = factory.BuildType1();
    var m2 = factory.BuildType2();

    So... what is m1 and m2 in this case? Yes you can figure it out, but not just by looking at it.

  • Don't know why my comment here didn't appear, but what I said was that the example that JV wrote will not compile:

    var people;

    // 10 lines of code

    people = new Dictionary();

    It would be impossible to use var in this case because variables declared with the var keyword has to be initialized in the same statement for type inference to work, thus the example would be as follows:

    Dictionary people;

    // 10 lines of code

    people = new Dictionary();

  • @Patrik,

    my personal preference is create what you want first, then leverage R# to do the nifty work.
    The way I work - I need a new dictionary of string, IPerson - as a result I type

    new Dictionary()

    no semicolon, no variable name -- who said I want a variable? Then leveraging R# to define variable or field, and if it's a variable, I choose var because I give it a fully quilified meaningful name, that does not require to look at the type each time I use it.
    So names like m1 or m2 would not be my preference, they are not descriptive enough :)

    As per comment that JV's, you are right, the link at msdn for var keyword should make it clear - something like "Implicitly Typed Local Variables and Arrays" cannot be split. Compiler will have no information about the type being assigned.

  • m1 and m2 were examples; there is no 1 to 1 mapping between a variable name and its type, no matter how well you name them.

  • @Sean

    Hmmm missed that line in the docs...my mistake.

    That being said I still think it makes for more difficult to read code when you aren't in VS...so while it may be usefull for practical coding, I think from a blogging/offline/print/educational perspective I hope that bloggers avoid it.

    Inside VS I don't have a problem with it, all ya gotta do is hover over it to inspect it.

    Ryan

  • @Ryan,

    I know where you coming from, and from that perspective you are right. I am trying to force myself to have code so short, that you won't have to mouse over to have a reminder what type the variable is. Actually, I am not using mouse at all in VS, it's a waste of time for me and I do everything with the keyboard. R# was the one that helped a lot. Also JP Boodhoo has showed me a few things that convenced me to drop it.

Comments have been disabled for this content.