Why do you use C#? Is it just because that’s what you where told to use? Are you one of those that hates VB.net with out any reasons other than, “its what hobbyist coders use”?.
I have a feeling there are some people that just don’t "get it". Unfortunately Jeff Atwood seems to be one of those. I have been reading his blog for years and he frequently brings up great points ideas and thoughts about software in general.
Unfortunately I have to strongly disagree with the path of one of his recent blogs: Department of Declaration Redundancy Department
To me that is "var abuse". If you are using C#, IMO, you should be using it as a statically typed language and use feature like var as a get out of jail free card when it is needed, or will provider significant "value add".
Using it everywhere make your code weak, in the world of C#.
If you want to use a dynamically typed/inferred language, use one! Don’t try to bend a statically typed language in nasty ways to do your work for you.
My major concern real here is maintenance. Introducing var as common place syntax means you are diluting two worlds. Coding standards may go by the way side for no reason other than, "I can use var so I will use var".
Would you mix you HTML, CSS, JavaScript, ASP.Net script tags and code behind all in one file? If so, then var is for you! Just don’t expect a job from me any time soon.
The irony is the people that say "yeah i use var all the time" are often the ones that say, "yeah but i would never use vb"..well why not?
My original reply:
comment like :
"Agreed. I use var all the time. It could be even more concise if they dropped the 'var'"
Make me ask: "Why are you coding in C#?"
Find a language that supports what you want! Try Iron python if you what to stay on the CRL/DRL.
I am keeping my "IFoo foo = new Foo();" syntax, thank you very much.
It concerns me that C# is trying to be the everything language. I give it about 3 years before no one whats to code in it anymore due to the lines be sooo blurred.
Use C# how is it supposed to be used, then use Boo, Iron python etc for more dynamic approaches.
Would you put all you JavaScript, CSS, ASP.Net and HTML in one file? I see this and being a similar scenario. 4 DIFFERENT "languages" solving different problems.
my $0.02
RhysC
skip to main |
skip to sidebar
A .Net blog with ramblings on code and other assorted things from a joe average developer.
About Me
My Favorites
Currently Reading
Daily Reads
My Current Bag of Tricks
Blog Archive
-
▼
2008
(104)
-
▼
July
(15)
- Castle --> M$!!
- WCF : Ron Jacobs is back!
- IoC 101
- Design Patterns 101
- Harnessing Multi Core Power
- TDD 101
- How Did You Get Started in Software Development?
- VAR Abuse
- Alt.Net London 2.0!
- nothing to do with code but...
- Mac Pro Windows User Experience Index
- MS test... why?
- Sandcastle source released
- Mac Pro Progress
- Mocks v Stubs
-
▼
July
(15)
6 comments:
I wrote about this once too because var felt "funny". I noticed it when resharper 4.0 told me everything should be declared with var.
http://www.timbarcz.com/blog/IsVarBetter.aspx
Apparently we're wrong.
I still like seeing types, however I'm trying to at least understand the other side and their view. It helps when I see guys like Ayende doing var...he's far smarter and more dogmatic than I
Yeah i have seen the big use use it a bit in his mock examples, which i am kind of OK with. A test is just a test, I would be concerned if he was using it in live code. I just dont see the point, use Boo if thats your gig.
well thats my opinion.. but hey, it also my blog :p
There a good link on Tims blog: http://resharper.blogspot.com/2008/03/varification-using-implicitly-typed.html
I must admit i am much more concerned with using var on dependencies than private or loacl varibles. if you are create an type in a mehtod that is disposed in that method and it is not a tightly coupled dependecy.. yeah use var.
What i dont like is
var createdobject;
createdobject = IoCContainer.Create[IFoo]();
If the createdobject object is declared out of scope.. to be honest i dont even know if you can do that... i type this at work on my VS2005 box.
That code would fail to compile because you've split the declaration and assignment. If you join them it will work (assuming that Create is a generic method with a type parameter of type IFoo). createdobject would then have a type of whatever the return type of Create is. If you're using a generic method in this context that's most likely IFoo.
The var keyword is not like variants. It takes the type that is assigned to it and is thereafter a statically typed variable of that type. You can't for instance declare var as a field or property type. Nor can the type of a variable change after the initial assignment, in this sense it is still very much static typing.
The var keyword is (except for a few special cases like LINQ) syntactic sugar that removes double specification of types. In most cases you'll get exactly the same IL out the other end. Youve just told the compiler a few less things it already knew.
OMG he is alive!!! Thanks for the input Colin, clearly you can see I have not even tried this (as you said it would not even compile). If it just just in method assignment, then yeah I spose im cool with it. However this woild assume methods are a sane size an intent is clearly expressed.
Out of curiosity how are you using this Colin?
I've been using var in a couple of places; primarily some personal projects and a VS 2008 conversion branch for a current work project. In the former I'm using it by default, in the later I'm making conversions where relevant (with the aid of Resharper).
In terms of the circumstances when I'll use it this varies by project. In new code I'll use it for most variable declarations. In existing code I'll make the changes if I'm modifying the code for other reasons, but generally not just because I can. As I tend to prefer descriptive (i.e. long) type and variable names this can make the code easier to read simply becuase it's not wider than the screen.
Ultimately it comes down to a question of whether the usage is a net gain in a particular situation. I feel in most cases it is because the context of the assignment makes it clear what the type is and repeating this is redundant. In some circumstances however an explict declaration is clearer. It's also mandatory in some cases, for instance when you need a variable to be of an interface type and you're assigning a class (which implements the interface). This may be necessary because you will need to assign other classes that only have the interface in common to the variable later.
I certainly agree that in long methods var would be something of an issue, but not significantly more than the problems with long method in general. If it's not on the screen it doesn't matter how it's declared. If I had to choose between refactoring long methods and the var keyword then I'd go with the refactoring every time. As I previously mentioned in most cases it's syntactic sugar, nice but hardly essential. Long methods are a design or implementation fault (not that we haven't all done this at one time or another).
Post a Comment