PS. These are katas, not production code, and I will one-line every single one of them I can, no matter how unreadable it gets.

Yes, it's fun.
I see your problem solving and understand that LINQ is a powerful tool that I need to learn. Urgent.)

I will not code like this in Project.

First of all, any decent debugger can debug one-liners. If yours can't, you need a new debugger.

1a. Case in point, if it were impossible to debug this one-liner, I wouldn't have been able to write it, since my first several passes broke.

Second, working code does not need to be debugged; only bugged code needs to be debugged (how do you remove something that isn't there; de-bug = remove-bug?) Anyway, assuming we live in an alternative universe where debugging is impossible with one-liners, it's trivial to add a few returns, debug, then remove those returns when everything works.

Finally, the style choice of "How many lines should this code be?" is a private, individual choice, and it is rude to criticize it in public. You can have all the opinions you want about code style, but, well, you know what they say about opinions, right?

PS. These are katas, not production code, and I will one-line every single one of them I can, no matter how unreadable it gets. Check my JS history; I can be pretty crazy with it.

Edit: PPS. I've looked at your comment history, and it seems you're new here, and you've taken it upon yourself to crusade against what you have arbitrarily decided to be poor coding style. I'd like to recommend that you get to know a community before you start barking at everyone. I'd also like to recommend that you drop this whole notion of "my style is The One True Way", because it's not, as was easily demonstrated by the aforementioned chris_w.

As far as most people are concerned, you can code in whatever style you like (as long as it's performant), but you have to be tolerant of everyone else's styles as well.

I apologised for the tone of my first post. You accepted my apology and have now recanted.

Indeed. Then you said, and I quote, "I didn't notice I was critisizing. Probably because I wasn't"

I attempted to demonstrate to you that you were. Not all criticism is bad; constructive criticism is welcome; that kind of criticism is not.

You've made it very clear that you have no interest in anything that I may have to offer.

If you have any valid, constructive criticism to offer, I'm all ears. So far, I've disagreed with all of the points you raised, and I explained why in detail. Being in vocal disagreement with you isn't the same thing as being disinterested. On the contrary; if I wasn't interested, I wouldn't be bothering to respond and your initial comment would have gone ignored.

have yet to address any of my concerns

Which ones did I miss?

In short, you have displayed no interest in anything other than winning

I carefully reviewed your points, came to the conclusion that I did not agree and responded to explain why in great detail. If it appears that I am only interested in "winning", it is only because so far I haven't agreed with any of your points. As it happens, code-maintainability and readability is a great passion of mine; it is something I have invested a lot of time and effort studying and honing and as such, I have formed strong and well-informed opinions on the topic, several of which we clearly disagree on; don't mistake that for stubborness.

bad for maintainability
very poor.
Being given kudos for it is even worse
Your code is undebuggable
Best Practices, definitely not.

Sounds like criticism to me, though none of which I agree with as explained in detail above.

I work for a successful software organisation that happily allows room for all levels of expertise.

And I'm sure any fresh college graduate would find the solution I implemented above more than readable, perfectly maintainable and no problem at all to understand. Your solutions here so far seem to make a lot of use of things like a temporary "retval" and additional nesting complexity in order to comply with the rules you adhere to such as "Only a single return statement is allowed". That kind of thing likely hinders those of both lower and higher experience levels.

Your second last paragraph was out of line as it has nothing to do with our conversation other than your imaginations about me.

You admitted yourself that you have to look into the functional programming paradigm and said that I "intriuged" you with it, suggesting that you don't currently have any experience with it. Furthermore, there is strong evidence throughout all of your comments that you're uncomfortable with that style of programming primarily because it's not the imperative style that you're used to writing yourself.

I hear your "don't be old-school" vibe

It's nothing to do with being "old-school". Some of the very first programming languages used some of the concepts discussed above. It's more that you seem to militantly adhere to rules, some of which aren't applicable or are out-dated or have exceptions, even where it is extremely detrimental to the readability and maintainability of your code. For example, you chastised me for having two return statements in my function, yet this is clearly a situation in which it makes sense and enhances the code. Your solutions, as I can see, go to some lengths to avoid this but actually to the detriment of the code; the result is code that is longer, more complex and less obvious.

Is there room for the rest of us?

I'm the one advocating for doing what generally makes sense in a given situation, while you're militantly chastising anybody who doesn't adhere to the general heuristics that you seem to have adopted as absolute rules.

Does resharper want to modify all your code to use 'var'

Yes, it's by default. It's not marked as a big warning, but as a suggestion. To me, I repeat, it's such a small difference that I think it's a matter of taste :) If i had to back up this in a more objective way, I would resort to the DRY principle. Writing string a = '' is like saying to time that it is a string, hence providing redundant information. I don't think that var a = '' has any readability problem :).

Weird.

As I said, I don't think it's weird, just stylistic decisions :)

Always code like it's real... :)

I can commit only a certain amount of time to codewars, I try to do the best I can in a reasonable amount of time :)

Thanks for commenting :)

I guess that var has a lot to do with opinions and personal feeling of the coder, is difficult to say what is better to use objectively, whether var or the actual type. Personally, I use var everywhere, probably because I am addicted to resharper, it's concise, and because I like to use type inference whenever I can, but as I said, I think it's more a matter of taste.

If I had to put this code in a real project, I guess I would have added a documentation for Seq, and maybe chose a better name :)