However, in the interests of completeness I had to post again as yesterday I quoted the C# reference as saying:

Overuse of var can make source code less readable for others. It is recommended to use var only when it is necessary, that is, when the variable will be used to store an anonymous type or a collection of anonymous types.

The var keyword can also be useful when the specific type of the variable is tedious to type on the keyboard, or is obvious, or does not add to the readability of the code. One example where var is helpful in this manner is with nested generic types such as those used with group operations. In the following query, the type of the query variable is IEnumerable<IEnumerable<Student>>. As long as you and others who must maintain your code understand this, there is no problem with using implicit typing for convenience and brevity.

Of course, we're not bound by what the authors of MSDN think. Often something is created without the creators realising the potential for that thing. Maybe var is the same. Who knows? Only time and convention will tell - certainly the vote is pretty split at the moment: You decide.

I thought about calling this post "Oh no! More on to var or not to var". I'll call the next one that :)

Comments are closed for this post.

"Often something is created without the creators realising the potential for that thing"

I sure hope that's not the case here. Type inference has been around for decades (and much more complete than C#'s). I'd hope people hired by MS would have background to know about these things ;).

If you want to see how this worked out, no need to wait a year. Go checkup on languages that have implemented this. The Wikipedia entry on type inference has a list of languages.

Posted by
redsolo
@
22 Jul 2008
3:11 AM
If people are saying they "var" every variable because its so much easier to read and write. Why not go the full monty, and removing the var declaration completly?

For me the reasons to use var are the reasons why it never should have been added.

Answer to come later...but I'll give you a hint, I'm not creating an account for a customer.

Oh, and yes, I work with people that write code that is this readable with 0 comments. Certain co-workers of mine send out 'code of the day' emails to each other for laughs - so don't think that this isn't a reality or an extreme example.

I'm all about readability and maintainability. The code above (non-primitive types) is a good example of being neither. If I threw this at you and said debug it...where would you start? The poll on 'var' was easy for me.

So guess folks, please....

Posted by
Brian Johnston
@
30 Jul 2008
8:01 PM
To follow up, in the above if I use type declarations (again I run into this stuff daily, I'll add comments to decipher):

ContractAccountControl z = this.Account

//Get the specified contract for the customer and //and initialize the account object if it hasn't beenContract c = Customer.Get(75234);if(c.Account == null){ Account a = Account.Get(c.AccountId);}

//Set the control Account property to the account//for the contractz.Account = a;

----

So yes I know there is a glaring bug, but that aside, my point that I'm showing is that without the type declaration, you don't even know you're working with a contract where the account for that contract is being displayed as part of a GUI control.

It could be argued that one would've figured this out if they had the context of the whole file - but that's not my point.

My point is that 'var' leads to developers who already write non-self-describing code that is barely maintainable to developers who write even worse code.

For those of you who will say this is a training issue or management issue, etc, then you must be blessed with being in shops where those things are an option, you need come join some of out here it was appears to me at least as very good size chunk of the world where people don't care about quality, they care about quantity because there business is to make money through means that have nothing to do with writing software (i.e. ITS) and despite what you want to believe, you are not there to write software, you are there to solve business problems and automate solutions and if cowboy coder Z can sling this crap and get it out there quicker, then 4 out 5 times, he's going to become the defacto lead developer...but that eventually trips up on itself and well anyway I'm digressing...

I work with several good developers, but I've also inherited some code written by rushed developers (don't know whether they were good or not, but I can tell by the code that they were rushed), and seen other code in previous stints that makes this code look very clean.

For example, imagine if you will combining the ability to 'var' items with clever variable names like axrfvo that is nested inside of a if statement that is nested inside another if statement that is nested in a for loop that is nested in another for loop that is nested in an if statement. This is what I deal with.

Yup, my job will make you a master of refactoring.

Posted by
Jeremy Gray
@
14 Aug 2008
11:49 PM
Having just discovered this post today through some link way back there in my history, I feel compelled to call BS on Brian:

var vs. lack of var isn't your problem here. Variables like 'z' are your problem, as are properties like "Account" (which wasn't an account, it was a ContractAccountControl.)

If you're going to set up an example to either knock down var, or knock down implicit declaration, or whatever it was that you were actually trying to do (since it wasn't all that clear even after reading your posts a few times) you might want to use an example that won't cause people to immediately write off your arguments.

Posted by
Michael Giagnocavo
@
15 Aug 2008
12:55 PM
@Brian: Jeremy is right. Saying that it's a training issue and you can't train is irrelevant. This is because if you have a process to stop people from using var (code review), then you'll have a process to stop people from writing dumbass code like that sample.

And on top of that, your argument is really only against stupid/poor developers and their organizations.

Using your logic, you can contrive all sorts of things. Here's a conclusion: "programmers should have to work in public spaces where I can easily see their monitors". Argument: Our developers suck so much they just surf Fark all day, and that's how this org is and we can't change that. That's not an argument against private workspaces, that's just a poor situation.

Posted by
Ellis
@
29 Aug 2008
1:16 AM
"you need come join some of out here it was appears to me at least as very good size chunk of the world where people don't care about quality"