C# 3.0 (Orcas) - implicit variables

B

bri189a

Senior Contributor
Joined
Sep 11, 2003
Messages
1,004
Location
VA
From documentation:

• Implicitly typed local variables, which permit the type of local variables to be inferred from the expressions used to initialize them

var i = 5;
var s = "Hello";
var d = 1.0;
var numbers = new int[] {1, 2, 3};
var orders = new Dictionary<int,Order>();

Is it me or does this take maintainability way down (especially when you through in a few 10's to 100's line of other code - what was s again? Now we get back to declaring objects:

strUser;
intID;
objWorkflow
decAmount;

Yeah - it's a pain enough to deal with in JavaScript - I don't really want to have to support this in compiled code too! Readability goes threw the floor, and if somebody has commented well or has a poor naming convention - good luck buddy!

Also they don't mention what happens if you do this:

Code: 
var s = "Sam";

//50 lines of code

s = 0D;  //notice I changed it to decimal

Does it throw a compile error? a run-time error? accept it?

Listen, I'm all about new features for increased output, but honestly - this is a step backwards when you think that a majority of the cost of an enterprise application isn't spent initially building it, but maintaining and extending it over time.

In fact I'd really like to see what all the 'features' of C# 3.0 are truely for - the way C# works now is pretty darn good IMNSHO and I'm a big believer in 'if it ain't broke don't fix it'. What are the business objectives being solved by these new features? Who really benifits? What is it doing now that can't be done currently? Is the current work arounds that these are solving that much trouble? How much of maintnance nightmare is going to cause? In otherwords a problem now I know what to look for, but now if that problem can be caused by doing some 1.1 way, 2.0 way, and 3.0 way - I have to look for 3 differant programming styles for a bug rather than one.
 
Last edited:
It's not as dire as you paint it. :)

All "var" does is cut down on clutter really. e.g.
Code: 
MyVeryLongGenericTypeName<MyVeryLongClassName> foo = new MyVeryLongGenericTypeName<MyVeryLongClassName>(...);
becomes
Code: 
var foo = new MyVeryLongGenericTypeName<MyVeryLongClassName>(...);
The type of the variable is determined by the initializer and cannot be changed (yes, it would be a compile-time error). Just like any other variable, if you hover your mouse over it you'll see it's type.
 
LOL:
These complaints about the new C# features are the exact same ones people always have about changes to any language. Scan the posts in "Random Thoughts" for complaints on the changes between VB6 and VB.NET. Substitute the VB6/VB.NET complaints with C#1 and C#3 and the posts are identical. Here's a rephrased quote that works for any language upgrade - this should probably be made a sticky:
I'd really like to see what all the 'features' of [new language] are truely for - the way [current language] works now is pretty darn good IMNSHO and I'm a big believer in 'if it ain't broke don't fix it'. What are the business objectives being solved by these new features? Who really benifits? What is it doing now that can't be done currently? Is the current work arounds that these are solving that much trouble? How much of maintnance nightmare is going to cause?
Click to expand...
The simple answer, as usual: if you don't like the new features then don't use them! If you're worried that others are using them, then stop worrying - you'll never be able to change how others program unless that's your job.

-ner
 
Nerseus said:
LOL:
These complaints about the new C# features are the exact same ones people always have about changes to any language.

I'd really like to see what all the 'features' of [new language] are truely for - the way [current language] works now is pretty darn good IMNSHO and I'm a big believer in 'if it ain't broke don't fix it'. What are the business objectives being solved by these new features? Who really benifits? What is it doing now that can't be done currently? Is the current work arounds that these are solving that much trouble? How much of maintnance nightmare is going to cause?
Click to expand...
It would probably be a good experience to go back to those posts and try to answer those questions. I honestly don't know how able we will be to answer them satisfactorily.

Nerseus said:
The simple answer, as usual: if you don't like the new features then don't use them! If you're worried that others are using them, then stop worrying - you'll never be able to change how others program unless that's your job.
-ner
Click to expand...
You are very close to contradicting yourself. Fill in some gaps and the logic clashes. As usual, the simple answer is nonsense, and I don't doubt that you know it. You can not participate in a programming community without having the same base skill set as the rest of the community, and it becomes exceedingly difficult to either make a living programming, or to make an interesting hobby of programming, without participating in programming communities. If you want your programming to be purposeful, you need to be part of the community, and you need to know the new features, hence we can not simply not use them!
 
marble_eater said:
If you want your programming to be purposeful, you need to be part of the community, and you need to know the new features, hence we can not simply not use them!
Click to expand...
Sure you can! You might be silly for doing so, but if you are more comfortable doing something in a certain way and you have no reason to learn the new way, then why make the switch? I agree that you should at least know about the new stuff -- as many features as possible for that matter -- as it will only make you a better developer. But it is by no means a requirement that everyone use or not use implicit variable declarations, for example. You'll still write code that is just great and works perfectly well. What will I be doing? I'll be learning the new stuff and learning when it is appropriate to use.

Here's another example...I never use Do-While loops. I just don't like them. I much prefer while loops and formulate my loop invariant and code flow to work with them instead of do-while. I guarantee my code does not suffer for it.
 
I suppose I should point out that even if we don't use the new features we still need to fully understand them, and new programmers still need to learn them, and if we want to use other people's code, there is a good chance that we will need to use the new features.
 
Good point Nersus. I'll go gripe elsewhere :)

However I still say it will be a pain to maintain if you don't have Intellesense.
 
Last edited:
From what I've seen, you wouldn't be the first to dislike this prospective "feature". I can tell you that I've literally wasted days cleaning up crappy VB6 code where junior programmers thought "variant" was a great idea. Non-typed variables was already a bad idea a decade ago.

I seriously doubt it if this feature makes it to release.
 
I really don't see what the big deal is. This is just a way to make potentially difficult to read code much easier. See IngisKahn's post above. Strong typing doesn't suddenly dissapear and it's not like you can't see what you declared it as just as easily whether the type is in the front of the statement or the back. Really, the only problem I see is if you var something and then initialize it incorrectly -- intend to use an int and declare a float or vice versa. But why you would type v-a-r instead of i-n-t in that case is beyond me. I don't see maintainability as an issue. You could shoot yourself in the foot, but var probably shouldn't be used for primitives anyway.
 
mskeel said:
I really don't see what the big deal is. ... I don't see maintainability as an issue. You could shoot yourself in the foot, but var probably shouldn't be used for primitives anyway.
Click to expand...

For most of us interested in software development and reading these posts, it's not personally a big deal since we're smart enough to know when to use it and why.

The problem is that it reduces the code quality of sub-programmers to zilch. If you never have to deal with one of these monkeys, then fine. I just know that within a year of this feature, I'll encounter an idiot who did this inappropriately all over the place.

Any of you who worked with many VB programmers in the 90's know exactly what I'm talking about - there are some who type semi-randomly and hope for the best until by chance the compiler gives them something that "runs" - if you let them be too lazy to have to enter the type, that's exactly what they'll do.
 
With the combination of implicitly typed variables and object initializers we get:
C#: 
var x = new { UpperLeft = new Point { X = 0, Y = 0 }, LowerRight = new Point { X = 5, Y = 5 } };
Anonymous types! Alright! We are declaring a variable of type... um... It's not that hard to figure out, but this is also a pretty simple example, and it isn't exactly intuitive. I certainly prefer:
C#: 
Rectangle X = new Rectangle(0, 0, 5, 5);
I can't really seeing anonymously typed variables being used much, but when they are... well, there's a disaster waiting to happen. I hope that anonymous types don't make the 3.0 cut, and I would prefer that implicit typing be restricted to initializers using the new keyword (hence the variable type will be there clear as day either way), but if not, it's not the end of the world. I just can't see the benefit of typing "var" instead of "int" or "bool".
 
Exactly - if:

MyClassName x = new MyClassName()

is so difficult that you have to:

var x = new MyClassName()

And for good measure, if you have a class name that's more than 8-12 characters it problems needs a name refactoring anyway.

What are you really gaining? It's not like you could just type M-y-C and then press Alt-Space and have it auto complete or narrowed down pretty far.

And as Jaco posted I work with plenty of ex VB6 programmers who made it into VB.NET (kicking and screaming) who still use #include in their ASP.NET projects (another example of something that is allowed that shouldn't be) - and let me say from experiance, his description of 'monkeys' and throwing crap together until the compiler lets it compile is a very accurate description. I wish I was priveledged enough not to have to deal with outsourced sub-par programmers (and I fully admit I'm not the best either...) - but until executives figure out they're spending more money supporting poorly written code than if they would've in-sourced or at least spent the extra to out-source worthy programmers, I will have to deal with these types.

I can see already some idiot right a function that looks like this:

public bool DoSomething(var x, var y, var z)
{
var a = x.CreateSomething()
var b = y.DoSomething(z)

return a.Modify(b)
}

Yeah, how's that for readability????? Support that when it's called 15 nested functions in!!!

Maybe type arguements can't be 'var' types...I don't know, but this is the kind of mess these people Jaco mentioned make - oh and it's written in VB with Option Strict/Explicit turned off to make it all the more fun.

Well said Jaco and way to bring my point home!
 
Last edited:
marble brings up anonymous types which is whole different story (and the one 3.0 feature that I feel a bit uneasy about).

And bri, come on! You wrote it yourself: implicit typing is for local variables only. How could a type safe language call a function on a variable without a type? And restricting names to 12 characters??? Good luck, especially with generic types.
 
You're right, I got off on a tangent and knee-jerked reacted - I just get stired up real easy, but the 12 characters thing...my point was if that you have:

MyClassForGettingSomeCommonFunctionality m = new MyClassForGettingSomeCommonFunctionality

(which I have) - it should have it's name refactored. And in my view, var is just a shortcut for you to not to have to type all of that.

I personally have written very few classes that are longer than 12 characters...in the above that gets you to the 'MyClassForGe' point - I'd say 20 is the abosulte tops before just being over-descriptive - comments and class descriptions should have a place - in the help file. A class name should be descriptive, but to the point.
 
Having such long names would certainly be commonplace whilst referencing objects that are in a namespace not included in the using section of a page (or in order to avoid clashes with the same name in differen't namespaces). For example I'm often writing System.Drawing.Rectangle as its the only place in a class I use something from that namespace. Combine this with a particularly long named namespace or class and you soon get very long names very quickly.
 
IngisKahn said:
marble brings up anonymous types which is whole different story (and the one 3.0 feature that I feel a bit uneasy about).
Click to expand...
Well, lemme explain why I think that anonymous types fall within the scope of this conversation. It might be possible to use anonymous types without implicit typing...
C#: 
Rectangle MyRect = new {UpperLeft = New Point{X = 0, Y = 0}, BottomRight = New Point{X = 5, Y = 5}};
Yeah, that hurts my brain a little, but I can make sense of it.
When combined with implicit typing, however...
C#: 
var Skoobideebop = new {UpperLeft = New Point{X = 0, Y = 0}, BottomRight = New Point{X = 5, Y = 5}};
we achieve a whole new level of unreadability. If anonymous types are vinegar, implicit typing is baking soda.


But now that I'm on the subject anonymous types, it seems more than just a little inefficient to me. Look at my second code example. (This is what I found when researching on .Net 1.1, maybe, hopefully, newer versions are better optimized.) When you break down the IL, you find that you are actually creating six structs, initializing them, calling three constructors, and performing three copy operations. Now we are using properties instead of parameters to initialize our structs (because new syntax lends itself to this), adding six function calls to set property values. This is a bit of overkill to create a rect. I don't expect this to happen for a rectangle, but when people begin to tailor their classes and structs to C# syntax, which I believe they will, in certain situations it could lead to loads of anonymous types, increasing cpu usage for data initialization tenfold. It might make your code very readable, but it could also kill you in any kind of data processing if you don't know what's going on under the hood. And now I'm done complaining. Sorry I got off topic.
 
Back
Top