Poor var (C#)
-
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
-
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
MiddleTommy wrote:
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.
LOL! Thank you for your responses. I enjoy a good discussion. I ended up blogging about var yesterday [^] after we started our discussion and it really seems people (including myself) are pretty set one way or the other. You're certainly right about comments, I try and use them as much as possible when I know others will be reviewing my code. And it really wouldn't make sense to refactor method names - generally a bad idea when it comes to an API.
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."