|
Nor is there any reason to bog down the reader with needless detail.
|
|
|
|
|
Never said so. The best readability you get if it's short but descriptive.
|
|
|
|
|
One of our juniors whent a little overboard with his names and made them so long, descriptive and sometimes too similar that the code became absolutely unreadable.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
I learned to write "easy understandable and maintainable code" the hard way, because in my company is long term maintainance the normal case, so we have to understand the code in 10 or more years. 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
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.
|
|
|
|
|
Hey, you spelled "gin" wrong - TWICE! 
Anything that is unrelated to elephants is irrelephant
Anonymous
-
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-
I'd just like a chance to prove that money can't make me happy.
Me, all the time
|
|
|
|
|
I substitute coffee at 3am with beer 
"I've seen more information on a frickin' sticky note!" - Dave Kreskowiak
|
|
|
|
|
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
