Proposal of using var in coding standards

Oct 6, 2010 at 7:01 AM

My preference. I like using implicitly typed local variable declarations so this:

var executable = Path.GetFileName(Environment.GetCommandLineArgs().First());

if (!args.Any()) {
    var showUsage = true;
    var usage = String.Format(CultureInfo.InvariantCulture, "Usage: {0} <manifest-file>", executable);
    var nuspecFiles = GetNuSpecFilesInDirectory();

Over this:

string executable = Path.GetFileName(Environment.GetCommandLineArgs().First());

if (!args.Any()) {
    bool showUsage = true;
    string usage = String.Format(CultureInfo.InvariantCulture, "Usage: {0} <manifest-file>", executable);
    string[] nuspecFiles = GetNuSpecFilesInDirectory();

If agreed I'll add this to our coding standards.

Oct 6, 2010 at 5:32 PM

Don't agree. The cases where var can be used are pretty obvious to me:

  • You have an anonymous type.
  • You're doing an awesome LINQ query that no one will understand (joking)
  • You can clearly tell what the type is from the rhs i.e. var value = (MyType)Doo();  or var foo = new Foo();
Oct 6, 2010 at 5:47 PM
  • Also, there are times when the type name is just too long to type. :)
Oct 6, 2010 at 6:05 PM

Sorry, not sure if I was clear in my statement. I want to use var everywhere (where possible).

Yes, if you have to specify the type (e.g. anonymous) go for it. But do we really want to write this:

MyType foo = (MyType)Doo();

I would rather just say:

var foo = (MyType)Doo();

Oct 6, 2010 at 6:07 PM
Edited Oct 6, 2010 at 6:07 PM

My third bullet was exactly that point :). 

Oct 6, 2010 at 6:09 PM

I've seriously lost the thread and your point David. I would like to see us using var where possible. I don't know where you stand.

Oct 6, 2010 at 6:33 PM

Ok, here's what I said:

The cases where var can be used are pretty obvious to me:

  • You have an anonymous type.
  • You can clearly tell what the type is from the right hand side of the expression 
  • i.e. var value = (MyType)Doo();  or var foo = new Foo();


So you're scenario covers this and I agree.

MyType foo = (MyType)Doo();

I would rather just say:

var foo = (MyType)Doo();

As long as I can tell what the type is (because it's clearly written on the right side of the expression) then it's fine.

Oct 6, 2010 at 6:35 PM

Thanks David. So that's one "yes" vote from dfowler ;)

Oct 6, 2010 at 6:50 PM
+1 for 'var' tasticness

On Wed, Oct 6, 2010 at 12:35 PM, bsimser <> wrote:

From: bsimser

Thanks David. So that's one "yes" vote from dfowler ;)

Read the full discussion online.

To add a post to this discussion, reply to this email (

To start a new discussion for this project, email

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at

Oct 6, 2010 at 6:53 PM

David, can you update our coding guidelines: Guidelines ?

Oct 6, 2010 at 7:00 PM
Six to one, half dozen to the other. I don't care either way.
"Be passionate in all you do"

Oct 6, 2010 at 7:15 PM

What David describes is generally how I like to use var as well.  Basically, use it whenever the type name already occurs in the statement, e.g. as a result of an 'as' or cast.

Oct 6, 2010 at 9:38 PM

+1 for always use var.

Oct 6, 2010 at 11:13 PM

Not always when it's clear

Oct 6, 2010 at 11:15 PM

Always use var until you can't.

If you think it isn't clear enough, improve your method / variable name.

Types are an implementation artifact, not the core of your algorithm.

Oct 7, 2010 at 12:17 AM

This isn't really an open discussion :). It's the coding style for nupack.

Oct 7, 2010 at 1:10 PM

Thanks for the input. I've updated the coding standards and will apply this in some global refactorings I'll submit at some point (after I get two monkeys off my back, cmdline parsing and xunit support).

Oct 7, 2010 at 5:11 PM
Edited Oct 7, 2010 at 5:11 PM

Lets not do any global refactoring. As you change files, change the style if it doesn't meet coding standards.

Oct 7, 2010 at 5:36 PM

Yeah, the new VS Power Tools has a feature that will reformat code when you save. If we use the same settings for that, we’d be ok. Also, for those using R#, we should check in a settings file with our conventions. Anyone want to volunteer to do that?

Oct 7, 2010 at 5:45 PM

Phil, can you point me to where the Power Tools formatter is? 'Cause our coding styles are killing me, and I don't have an R# license.

Oct 7, 2010 at 6:04 PM

I don't like the sound of that formatter. Especially if you're going to be changing existing code. Just follow the guidelines, you don't have to like them, but you follow them.

Oct 7, 2010 at 6:05 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Oct 7, 2010 at 6:12 PM

davidfowl, I don't think anyone is suggesting we don't follow the style strictures. I think we're all aware that we don't have to like 'em.

More importantly, if the results meet the style strictures, what does it matter if we individually use a tool? I don't think we're suggesting you'd have to use it. At least I'm certainly not.

Oct 7, 2010 at 6:13 PM

I'm anticipating the potential damage :D

Oct 7, 2010 at 6:34 PM

davidfowl, I don't understand the concern for collateral damage, as we have a formal code review process. I'm not suggesting we make global changes, if that's your concern; I'm speaking to new and modified files meeting the same style strictures you've already imposed. And, I'm not speaking to a specific tool. Am I missing something?

Oct 7, 2010 at 6:40 PM

Per Drew’s point, if the tool is configured to meet our guidelines, and it only formats files that *you explicitly change*, then I don’t see the problem.

If the commit doesn’t meet the guidelines, I’ll let you provide a virtual whipping on the pull requestor. How’s that? ;)

David, it’s time to let go of the inner control freak just a tiny bit and trust that people will try to do the right thing. J