|
Then instead of the question:
"Could I read and understand this code at 3am after 10 cups of coffee?"
it should be:
"Could I read and understand any code at 3am after 10 beer?"
If the answer is yes... the probability to get a job here were I live would increase
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Nelek wrote: If the answer is yes...
Of course, and the minimum ABV (alcohol by volume) be about 7% 
"I've seen more information on a frickin' sticky note!" - Dave Kreskowiak
|
|
|
|
|
Duncan Edwards Jones wrote: Could I read and understand this code at 3am after 10 cups of coffee.
Because one night you will be reading that code at 3am after 10 cups of coffee.
I stopped working there 4 years ago. Not all jobs are insane.
|
|
|
|
|
I stopped working there three years ago.
People still work there ![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Just keep one-lettering everything.
With a little practice you'll be writing Haskell (or any functional language) without even knowing it 
It's maddening!
For anonymous lambda's it's ok though.
Unless they get complicated or nested, especially when a single letter can be ambiguous.
|
|
|
|
|
I'd agree:
var pauls = names.Where(n => n.StartsWith("Paul ");
I think that's fine - if it gets complicated, then yes, you need complex names. but just as "x" and "y" are fine for coordinates, I think you start to lose the point a bit if you use "name" instead of "n" in the above - especially as it's likely to name been used in the same context elsewhere anyway.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
OriginalGriff wrote: I think that's fine - if it gets complicated, then yes, you need complex names
Agree. In your example writing name instead of n does not add anything.
I just noticed that the survey refers to trivial lambdas, so I should have answered the first option but I said context-dependent.  But really, I would only spell it out for non-trivial lambdas (if it adds clarity).
Kevin
|
|
|
|
|
Well spotted, but the response does indicate that somehow they are allowing for complex trivial lambdas, or is that trivially complex lambda's.
In the example given in the question, I would definitely go with Items.Select(product => product.ID), as the collection's name (Items) does not imply to me that the collection contains products.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Rob Grainger wrote: In the example given in the question, I would definitely go with Items.Select(product => product.ID), as the collection's name (Items) does not imply to me that the collection contains products.
Yes, that makes sense. As ever, when applying rules/recommendations we should always keep our brains engaged.
Kevin
|
|
|
|
|
I'd refactor Items to Products and then use Products.Select(x => x.ID)
|
|
|
|
|
Sander Rossel wrote: Just keep one-lettering everything.
That way, the next person to look at the code can use four letters!
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I believe that's called offensive coding  
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
