Dense code
time to read 1 min | 73 words
The amount of information that you can push into just a few lines of code keeps amazing me.
This is doing so much stuff that it is just creepy. And yes, it is quite elegant at the same time, since it is handling the required scenario in such a simple manner.
Comments
You could replace the "Count() == 0" conditions with "!Any()" for additional elegance :)
Yeah, quite scary, barely debuggable, but I vote for such style. Imho a drastic increase in the quality of both reading (conciseness = less to read, easier to understand) and writing (conciseness = less points to introduce an error) far supercedes these inconveniences. And after all most of the time it's only the signature that matters to this method's user.
The Pluralize-method seems a bit naive. Try calling it with "boy" or "monkey".
Pluralize :) ... lol
Regarding pluralization. Some time ago I came across an article about pluralization for English: www.csse.monash.edu.au/.../Plurals.html. Quite like it tbh.
You might want to look at .ToList()ing the enumerabe variables, as leaving them as enumerable will cause "elements" and "attributes" variable to be re-evaluated each time you do anything with them (such as attributes.Count()) - this method may perform a little faster as well...
@Eugene
The code is perfectly debuggable. You realist the debugger allows you to step through linq statements even on vs 2008.
Andrew Peters has a port of inflector for .net http://andrewpeters.net/inflectornet/.
Or let it pluralize "status" :)
Is it Newtonsoft.Json?
Pls comment your code :)
Rafal,
Yes
@Thilak
Debugging lazy LINQ-to-Objects queries is quite inconvenient in comparison with debugging regular collections. Yeh, you can still "enumerate the results", but it's an extra click/keystroke as opposed to watching a collection with a debug visualizer.
And, what's more important, you can't watch the result of partial application of a query, e.g. the result of lines 4 and 5, but not 6 on the screenshot above). The best what I can come with is to manually refactor subquery into a local variable, but this requires manual work tho R# can alleviate it significantly. Usually, one has to repeat this for a few times because it's rare to find a bug at the very first watch you perform.
Comment preview