Poor var (C#)
-
I dont understand var bashing. It is a shortcut use it or dont use it. You can turn intellisense off too. As for readability? I find var makes me digg to understand code more than using traditional static type declarations as a crutch. If var is confusing your understanding of code then your methods are too long and too complex. Also you can always hover over a variable to have visual studio tell you the type of a var declared object.
I myself have no problem with var. But it isn't a shortcut (see my post above). In fact, your argument is contradicting. You're saying it forces you to dig in more and requires the additional step of hovering over the variable to understand the type. You're saying it's a shortcut, but what you're describing is additional work. Using var has its place, most especially when working with anonymous types. Another place I use it a lot is unit testing where I am declaring a variable which is an interface and assigning it the value of a mock or stub. But it hasn't ever saved me typing over intellisense except in the latter case. If you choose to use it as a convention because you prefer it, so be it. I won't argue with you and if I work on your project I wouldn't complain either. I don't care that much wither I use it or not. But stop saying it is a shortcut because it isn't unless you code in notepad (I've only ever met one developer who did). As an additional argument against hovering over code snippets, if you are writing an article in code project or posting in the forums you cannot get any help. Also, something I often do because I want to open a code file w/o the overhead of opening an entire project I will open a file in notepad when I don't already have it open - I do this because it saves me time (I have enough RAM to open as many instances of VS as I like). Again, I can't hover over it. So while there is nothing *wrong* with using var, saying it is a shortcut isn't *right*.
Code responsibly: OWASP.org Mark's blog: www.developMENTALmadness.com Bill Cosby - "A word to the wise ain't necessary - it's the stupid ones that need the advice."
-
That's my favourite way too. You can see immediately that it's a collection.
-
Possibly because if you want to find a
Listvariable in a long list of declarations, it's much easier to run your eye down a vertical line of types on the left hand side of the=than to have to scan left and right on each line to find the declaration type.varfor Linq queries I can see the value of,varfor every declaration is confusing.I hope you realise that hamsters are very creative when it comes to revenge. - Elaine
Apart from the answers below, there is always 1) ctrl+f, 2) the fact that by writing less code you can find the info you need easier, it just sticks out.
-
I'll want you to explain me what you would use for a linq query that returns an anonymous type, or what is not enough strongly typed for you in the code var records = new List(); For me, var is a blessing. It saves me of repeating redundant information (why the hell would I want to say in the left AND the right hand side that this is a damned List of Records?).
+1 get resharper and you ll get vars everywhere :)
-
I myself have no problem with var. But it isn't a shortcut (see my post above). In fact, your argument is contradicting. You're saying it forces you to dig in more and requires the additional step of hovering over the variable to understand the type. You're saying it's a shortcut, but what you're describing is additional work. Using var has its place, most especially when working with anonymous types. Another place I use it a lot is unit testing where I am declaring a variable which is an interface and assigning it the value of a mock or stub. But it hasn't ever saved me typing over intellisense except in the latter case. If you choose to use it as a convention because you prefer it, so be it. I won't argue with you and if I work on your project I wouldn't complain either. I don't care that much wither I use it or not. But stop saying it is a shortcut because it isn't unless you code in notepad (I've only ever met one developer who did). As an additional argument against hovering over code snippets, if you are writing an article in code project or posting in the forums you cannot get any help. Also, something I often do because I want to open a code file w/o the overhead of opening an entire project I will open a file in notepad when I don't already have it open - I do this because it saves me time (I have enough RAM to open as many instances of VS as I like). Again, I can't hover over it. So while there is nothing *wrong* with using var, saying it is a shortcut isn't *right*.
Code responsibly: OWASP.org Mark's blog: www.developMENTALmadness.com Bill Cosby - "A word to the wise ain't necessary - it's the stupid ones that need the advice."
I agree with you that in some situations it will not save you time. But I am all for uniformity. As a whole if you use var you will code faster. Not only Anonymous types is it a helper. In any Declaration not using the new keyword var comes out on top. Especially if you code like me and refactor a lot. example var coordinate = point.GetCoordinates(); if the return type of GetCoordinates ever changes you dont have to go fix all those declarations. Also often when you compile and a declaration is off further errors are not shown until you fix the declaration and recompile (unless you use Resharper). But to clarify when I said shortcut I was not thinking of keystrokes. Because of the "contradictions" you pointed out let me expound my explanation to un-contradict myself. When you understand the code you are working on Type declaration is not needed. Also The lack of type declaration does not slow you down. When you understand the code you are working on you can code faster because of that understanding. If using var forces you to understand the code better then in the long run you generally code faster. Also as far as I am concerned they should have let us do this coordinate = point.GetCoordinates(); Let the compiler figure out coordinate is a new variable and declare it. But that would have really upset some "C syntax" fan boys. Perhaps officially shortcut is the wrong word. Though I did not mean it the way you suggest I meant it. I could go on and on how var saves me time or shortcut in other words but Let me revoke shortcut and use shorthand instead. var is a shorthand that will save you time(IMHO)
-
I agree with you that in some situations it will not save you time. But I am all for uniformity. As a whole if you use var you will code faster. Not only Anonymous types is it a helper. In any Declaration not using the new keyword var comes out on top. Especially if you code like me and refactor a lot. example var coordinate = point.GetCoordinates(); if the return type of GetCoordinates ever changes you dont have to go fix all those declarations. Also often when you compile and a declaration is off further errors are not shown until you fix the declaration and recompile (unless you use Resharper). But to clarify when I said shortcut I was not thinking of keystrokes. Because of the "contradictions" you pointed out let me expound my explanation to un-contradict myself. When you understand the code you are working on Type declaration is not needed. Also The lack of type declaration does not slow you down. When you understand the code you are working on you can code faster because of that understanding. If using var forces you to understand the code better then in the long run you generally code faster. Also as far as I am concerned they should have let us do this coordinate = point.GetCoordinates(); Let the compiler figure out coordinate is a new variable and declare it. But that would have really upset some "C syntax" fan boys. Perhaps officially shortcut is the wrong word. Though I did not mean it the way you suggest I meant it. I could go on and on how var saves me time or shortcut in other words but Let me revoke shortcut and use shorthand instead. var is a shorthand that will save you time(IMHO)
I like your argument. I can see that refactoring support is a strong plus for var. But if you're refactoring the type do you also refactor the method name? The reason I ask is not to belittle, but rather because the argument I have heard for using var in your scenario is that the method name clearly denotes the type - GetCoordinates returns type Coordinates (or a generic collection of Coordinate types). And so the method name is what maintains readability. I also believe part of this discussion is rooted in context. My experience has been that regardless of the length of time I'm on the project (I've been on a project anywhere from 3 months to 7 years) there's always someone new who comes in or I eventually move to another project. Readability has a high value for me. Plus when I'm working on a team I'd rather have the code read easy so I don't get phone calls on my day off (this doesn't really happen, but rather an extrapolated hypothetical). Regardless of how it sounds, I'm not really against var. I definitely use it in some cases but I prefer not to use it as my main method of declaring local variables outside of using it for anonymous types and unit testing.
Code responsibly: OWASP.org Mark's blog: www.developMENTALmadness.com Bill Cosby - "A word to the wise ain't necessary - it's the stupid ones that need the advice."
-
JavaScript. Or did you not mean to include dynamic languages?
But fortunately we have the nanny-state politicians who can step in to protect us poor stupid consumers, most of whom would not know a JVM from a frozen chicken. Bruce Pierson
Because programming is an art, not a science. Marc Clifton
I gave up when I couldn't spell "egg". Justine AllenI'm not much of a JavaScript user, but doesn't var in JavaScript act like a variant in VB? That is, a single variable can be assigned values of different types. Var in C# is nice because it enforces one type (i.e., it compile-time checks the type).
-
Vb has it but they managed to re-use the
dimkeyword rather that creating a newvarkeyword. Normal Declarations (without using var):C# : int x;
VB : dim x as integerUsing var (and Option Infer in VB)
C# : var x = 5;
VB : dim x = 5Note that VB as also a nice compact
dim ... as new ...syntax:C# : var x = new Button();
VB : dim x as new Button()Both language look very similar to me now.
Huh, I never thought of that before. I just gained a little more respect for VB (very little ;P ). It's still not quite as efficient as var in C# though. VB:
Dim x As Button = SomeButtonMakingMethod()
C#:
// Never mentions the Button type.
var x = SomeButtonMakingMethod();Looks like VB can do something like that with option infer, but I'm pretty sure that came out around the same time that C# var did (based on my completely unknowledgable google search just now). So I guess the VB would go something like this (with option infer turned on):
' Never mentions the Button type.
Dim x = SomeButtonMakingMethod() -
unsafewas named so 'scary' and buried under an extra compiler option that nearly no one is using it. I've seen code doing manual marshaling (Marshal.AllocHGlobal,Marshal.Copy, etc.) for P/Invoke calls which could have been replaced with a simplefixedblock around the P/Invoke call.I don't think any of the Marshal calls let you point at arbitrary memory addresses, does it? It probably is a tad safer than unsafe. Correct me if I'm wrong.
-
That's what I do, but I was trying to establish some sort of raport with a variably challenged paradigm. :laugh:
-
I don't think any of the Marshal calls let you point at arbitrary memory addresses, does it? It probably is a tad safer than unsafe. Correct me if I'm wrong.
This will copy one byte to a random memory address:
int rnd = new Random().Next();
Marshal.Copy(new byte[] { 42 }, 0, (IntPtr)rnd, 1);How is this safer than
unsafe {
*((byte*)rnd) = 42;
}? At least with unsafe code, you see the "unsafe" warning right in the code.
-
I'm not much of a JavaScript user, but doesn't var in JavaScript act like a variant in VB? That is, a single variable can be assigned values of different types. Var in C# is nice because it enforces one type (i.e., it compile-time checks the type).
aspdotnetdev wrote:
doesn't var in JavaScript act like a variant in VB?
Pretty much. The only notable difference is that it works that way consistently - there's no appreciable difference between a variable holding a value and one holding a reference to an object. C#'s var is just a handy shorthand notation for a normal typed variable... I can't help but think it would be much more useful if C# had something like C++-style templates... And sure enough, the next version of C++ introduces its own version of
varwith theautokeyword! :-) -
This will copy one byte to a random memory address:
int rnd = new Random().Next();
Marshal.Copy(new byte[] { 42 }, 0, (IntPtr)rnd, 1);How is this safer than
unsafe {
*((byte*)rnd) = 42;
}? At least with unsafe code, you see the "unsafe" warning right in the code.
Ah. I've hardly had a use for most Marshal calls, exactly for that reason.
-
~Anders wrote:
That way, you're not repeating yourself...
... and if I have a box of rocks, the label just says rocks.
-
Hmmm... what if object had worked like var to begin with? :suss:
PIEBALDconsult wrote:
Hmmm... what if object had worked like var to begin with?
Then we would need something that worked like object.
-
PIEBALDconsult wrote:
Hmmm... what if object had worked like var to begin with?
Then we would need something that worked like object.
Would we?
-
Would we?
Yes, we would. All sorts of things would break if something declared as object became something else. Something else can be assigned to it, but that's not the same thing. In fact anything can be assigned to it. That's the point.
-
I'll want you to explain me what you would use for a linq query that returns an anonymous type, or what is not enough strongly typed for you in the code var records = new List(); For me, var is a blessing. It saves me of repeating redundant information (why the hell would I want to say in the left AND the right hand side that this is a damned List of Records?).
I haven't used C# 3 that much yet but my guess is that something like var just takes a while to get used to. It's probably a bit like when we were all (well,a lot of us) Hungarian notation enthusiasts back in the C/C++/VB days. When first encountering a coding style that shuns it (e.g., .NET) our first thought is "but I can't see at a glance what the types are anymore!" However, nowadays I hate Hungarian and, to be honest, I'd abandoned it about a year before .NET was released. I expect that going forward and with the growing ascendancy of the functional paradigm var will increasingly seem natural.
Kevin
-
If you look at this week's poll forum, you can see some pretty nasty comments about the C# var keyword. People seem to have mistaken it to be equivalent to the VB6/COM VARIANT data type. A closer equivalent to the VB6/COM VARIANT would be C# 4.0's dynamic keyword. But to attack var based on some wrong assumptions is sad. Remember, all's fair in love and var ;P
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
My latest book : C++/CLI in Action / Amazon.com linkNishant Sivakumar wrote:
People seem to have mistaken it to be equivalent to the VB6/COM VARIANT data type
Yes this has been ongoing for a year. It's a bit unfortunate that they chose "var" rather than another keyword. People also mistake its meaning for JavaScript's var. However, C# is not alone. Scala also uses var for its type inference. (It uses val for functional immutability.) Nevertheless, despite unfortunate terminology people just need to apply a few moments' thought to these matters before shooting from the hip. Though to be fair there are many critics of var in that thread who fully understand what it means. They just prefer type explicitness to inference.
Kevin
-
I like your argument. I can see that refactoring support is a strong plus for var. But if you're refactoring the type do you also refactor the method name? The reason I ask is not to belittle, but rather because the argument I have heard for using var in your scenario is that the method name clearly denotes the type - GetCoordinates returns type Coordinates (or a generic collection of Coordinate types). And so the method name is what maintains readability. I also believe part of this discussion is rooted in context. My experience has been that regardless of the length of time I'm on the project (I've been on a project anywhere from 3 months to 7 years) there's always someone new who comes in or I eventually move to another project. Readability has a high value for me. Plus when I'm working on a team I'd rather have the code read easy so I don't get phone calls on my day off (this doesn't really happen, but rather an extrapolated hypothetical). Regardless of how it sounds, I'm not really against var. I definitely use it in some cases but I prefer not to use it as my main method of declaring local variables outside of using it for anonymous types and unit testing.
Code responsibly: OWASP.org Mark's blog: www.developMENTALmadness.com Bill Cosby - "A word to the wise ain't necessary - it's the stupid ones that need the advice."
I personally would not refactor the method name. My method names reflect what the method does not what it returns. It is pure coincidence that many times the object and method coincide. GetCoordinates could return a int[], IEnumerable<int>, List<int>, or a Coordinate object with x,y,and z properties and I would leave the method name alone. I am and always have been a lone developer. I dont have much experience working constantly with teammates code. I do find that relevant //comments make others code much more readable to me than any type declaration. Funny, I feel like I am Microsoft right now advertising the $2500 Total Cost of Ownership of a Win Server is less than a Free Linux OS. I guess everything all depends on who is listening. And where their skills are. (Like you said)
modified on Friday, August 21, 2009 9:29 AM