|
Agree completey, and I will add that if x,y,z,etc bother you I highly doubt the other devs on the team will care if you refactor the 'x' into 'theNewFooToInsert'. Since the linq statement is fully enclosed the refactor can be done 100% using the tools built into VS or ReSharper... making it arbitrarily easy to do.
|
|
|
|
|
Haha, if I touch the code, I refactor it just in the opposite direction!
sortItem => i ! 
|
|
|
|
|
Sorry, item is about as meaningful as t. Except typing out item is more verbose.
|
|
|
|
|
|
We can only hope they are stuck maintaining their own code.
I loathe the lazy use of var.
|
|
|
|
|
Why is that mate? It helps with little to no compromise, does it not?
Dictionary<string, IList<Person>> someDictionary = new Dictionary<string, IList<Person>>()
vs.
var someDictionary = new Dictionary<string, IList<Person>>()
even
var order = GetOrder(orderId)
is hinting with (1) the variable name and (2) the function name
and
var users = account.Select(a => new { Name = a.FullName, Role = a.Role } )
is simply cool.
Or are you referring to things like the following?
var money = 123m
|
|
|
|
|
Quote: var money = 123m
One of my pet peeves 
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
It compromises all over the place!
It saves you a couple of seconds of typing, but makes it harder to maintain because you can't just glance at the code and see what type a variable is.
When you see code like:
var order = GetOrder(orderId); You can't trust that order is of type Order because you are relying on the previous programmer (who you know to be lazy) to have still returned an Order from his method and not something totally different but been too lazy to change the name!
Seeing it as:
Order order = GetOrder(orderId); Make it absolutely obvious at a glance - and will immediately throw a compiler error if you change the method return type. Or if the wrong using block has been added and GetOrder comes from the wrong assembly alltogether.
Yes, these are extreme cases - but an extra second or two of your time and it would be clear.
var has it's place, and it's vital for Linq - but that's where it should stay! 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
The entire point of
var order = GetOrder(orderId);
is to be able to change the return type of your method, without having to track back through all the usages of that method and update all of that code as well.
That said this is the one usage of var where I get a little uncomfortable for the same reasons you said.
Generally speaking code using var as opposed to the actual type is easier to work on, less touch points while refactoring.
|
|
|
|
|
No, it is not.
I really want committed and released code to break on that line on a future change of the GetOrder return type. While developing 'var' is my friend and when done the "use explicit type" refactor option is. 
|
|
|
|
|
OriginalGriff wrote: been too lazy to change the name!
Ha!
The other day I wrote a GetType sort of method, it returned a Type. But then I decided to have it return a ConstructorInfo instead -- but I didn't change the name!  (Until the following day.)
|
|
|
|
|
|
I have to agree to an extent. Consider the following:
var user = new User();
This is fine imho because it explicitly states the type on the right. I don't mind seeing types on the right with a var on the declaration of type because it is still right there.
User user = new User();
This just feels unnecessary to me because you are stating it in two places;
var user = GetUser(userId);
I don't like this one either as the type of user can be assumed, but isn't immediately obvious in more complicated examples. In this example, sure, you can assume user, but what if you were actually returning:
IQueryable<User> user = GetUser(userId);
because for some odd business reason, a user consisted of multiple users. It is still a single base user in this example that logged in, but he has multiple user objects. Returning the IQueryable allows us to further filter afterwards, but it isn't obvious.
So, my own idea of a go to is if it is explicitly stated on the right, var on the left is fine. If not, then no. Even if it appears to be an obvious return value, you don't truly know unless you have intimate knowledge of the code.
Steve
|
|
|
|
|
Everyone prefers a minified version of code, you know...
You have just been Sharapova'd.
|
|
|
|
|
Agent__007 wrote: Everyone prefers a minified version of code
Exactly. I removed the space bar from my keyboard because I never use it. 
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
It was still taught in school 10 years ago. I actually like the single letter counters as it is an indication in itself. Personally I mostly use it in for loops.
as PIEBALDconsult said: it's a throw away.
|
|
|
|
|
Do you find LINQ too much terse and add verbosity on purpose? 
On the serious side, I fully agree with our PIEBALD.
|
|
|
|
|
Obviously, you never were a script kiddie...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
|
I have to admit I use single characters for linq but I do at least try to to use the first letter of the object type (Person => p) etc.
I am not a big fan of var. I think it encourages lazy programming, though used well it makes sense.
|
|
|
|
|
Quote: I am not a big fan of var. I think it encourages lazy programming, though used well it makes sense.
Rarely is the "var" keyword used as it was intended. I blame this on lazy programmers blindly following ReSharper's suggestion to replace every single variable declaration with "var".
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Dominic Burford wrote: blindly following ReSharper's suggestion to replace every single variable declaration with "var"
At that suggestion I removed ReSharper for good...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Dominic Burford wrote: blindly following ReSharper's suggestion to replace every single variable declaration with "var".
My Resharper doesn't do that, and I don't think I've changed any of the defaults 
Even obvious stuff like:
string message = string.Format("Error in xyz method: {0}", ex.Message);
doesn't get flagged by it.
|
|
|
|
|
thought someone would mention this (but then read the dislike of var  )
With
return source.Select(t => new
{
Index = rand.Next(),
Value = t
})
What is 't' short for? Table?
With loops, 'i' and 'x' (I assume) come from iterator and Maths use of variables.
(then subsequently y follows from 'x')
with linq, it is a sort of replacement for the item working on.
In the case above 'source'
so maybe 's' or 'src' if 'source' is too long to type.
|
|
|
|
|
Because LINQ is evil.
Regards,
Rob Philpott.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
