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.