In previous posts you might have seen that I was somewhat enthusiastic about the "auto" keyword in C++, so it might be natural to assume that I'd feel the same about the "var" keyword in C#. This is rather unfortunately not the case, allow me to expand a little as to why my feelings about the same functionality in two different languages are not strictly exactly the same.
I'll do it tomorrow, honest!
I'm sort of afraid a little that I'm going to start upsetting people here, so I shall start by saying this. I am generalizing here and not stereotyping, not everyone is the same and you may indeed be an exception to the rule, but this is generally what I find to be true.
C++ programmers tend to be less lazy than their C# counterparts. What do I mean by this? Well, normally when I'm looking at code written by a C++ programmer (in any language) it tends to be easier to read and maintain. It's because C++ can be painful enough without having to add extra complexity or obfuscation. Code written by C# programmers tends to be a little lazier, things need tidying up here, stuff is left lying around over there and it generally has that "I'll do it tomorrow" kind of feel to it.
Now don't get me wrong, there is a lot of very nicely written C# code out there, but I tend to find that the people who have written it come from a C/C++ background or have a lot of experience with those or similar languages.
So why should this matter? Well, when I think of C++ programmers using the "auto" keyword I tend to think of code coming out looking like this:
- map<int, vector<string>> MyFunction() { ... }
- void SomeOtherFunction()
- {
- auto result = MyFunction();
- }
Which is easy to follow, I know when I look in the "SomeOtherFunction" code that I just need to find the "MyFunction" method to see what the type will be (or use the functionality of the IDE), and importantly I know what the code is trying to do without looking this information up. When I think of C# developers using the "var" keyword then I tend to think of code coming out looking like this (and I have seen this):
- void MyFunction()
- {
- var a = 1;
- var b = 2;
- var c = "Something";
- ...
- var x = a + b;
- }
Which, okay, is readable and I can make out what is happening but I no longer have clue about the intent of the code; is "a" meant to be a short, an int or a long, maybe it should have been a double? We could have put some modifiers in there, but that's still not as easy to read. I just know that if a C++ programmer had written it that we'd have some types in there and the intent would become obvious. And this isn't just me worrying about something that probably wont happen, I've seen numerous people write code in this way.
What I meant was...
The thing is that the intent of the code is about as important as the code itself. If I say that a variable is a 64bit integer then it means that I'm expecting some pretty big values in there, similarly if I proclaimed it to be a 16bit integer then I'm expecting very small values. This kind of information can be invaluable to a maintainer, who might not be some unknown person looking at the code 5 years after you've written it, it might be you after you've spent 2 weeks on a different project and can't quite remember why you wrote something a specific way.
So is "var" a good thing? Well I would say it is, but like most things it should be used responsibly and never at the cost of losing the intent of the what you are trying to write. If you're not sure about it, then talk to someone about it, or write the code the way you want and give it to someone who hasn't seen it and ask them if they know what it's trying to do. If they pull a face then change it, if they know what the intent of the code is without asking too many (what you would consider) obvious questions then it's good to go.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
No comments:
Post a Comment