|
Anyone would think you don't want to do tomorrows!
Ok, let's see... the clue is "Maaaaaaaaaaaaaaaate!" and the last two letters are the same...
Got it!
It has to be: AUSEE
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I see what you mean, I was thinking more along the lines of ☑ ☑ ☑ ☑ ☑ Mate!
|
|
|
|
|
Tick mate?
PooperPig - Coming Soon
|
|
|
|
|
Close, think of another word for tick and you've got it.
|
|
|
|
|
Ixodes ricinus?
PooperPig - Coming Soon
|
|
|
|
|
|
_Maxxx_ wrote: Clue: c'mon you buggers, don't be mean!
I thought I'd got it until then! Now I'm confused...
I still think it's a game, for two people...Hmm...
Is it Knifey-Spoony?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
OriginalGriff wrote: a game, for two people
Shagg?
PooperPig - Coming Soon
|
|
|
|
|
We've spent 20 years trying to teach developers not to use variables like i ,j and k . So why is it that every time I see some LINQ code it's like this:
return source.Select(t => new
{
Index = rand.Next(),
Value = t
})
.OrderBy(p => p.Index)
.Select(p => p.Value);
Is it really that painful to do
return source.Select(item => new
{
Index = randomiser.Next(),
Value = item
})
.OrderBy(sortItem => sortItem.Index)
.Select(sortItem => sortItem.Value);
Or am I just too old and grumpy for my own good.
cheers
Chris Maunder
|
|
|
|
|
I disagree, the single-letter name (in a tiny scope) clearly indicates that the reader needn't spend any extra time thinking about the value. It's a throw-away.
|
|
|
|
|
PIEBALDconsult wrote: clearly indicates that the reader needn't spend any extra time thinking about the value. It's a throw-away.
Which is fine when you're writing it, or just reading through the code - but not when you're trying to debug non working code (esp. when more complex than the example) you need to stop and decipher.
PooperPig - Coming Soon
|
|
|
|
|
Quote: (esp. when more complex than the example)
But that's the key. We're not talking about thing more complex.
Truth,
James
|
|
|
|
|
I was
I think the op was talking in general, giving a simple example .
PooperPig - Coming Soon
|
|
|
|
|
I love when someone writes a library and uses single-letters for the parameters. It makes finding out what the function actually needs very difficult.
|
|
|
|
|
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.)
|
|
|
|