well i would advise to studdy Riemman Sums then, you'll understand where the code comes from ;)

Use spoiler flag next time, please.

I like it when the gloves come off Voile, so now I'll be blunt too. You make an unfounded assertion that I didn't understand the original idea (presumably because it makes you feel all big and superior), and then you write arse-gravy about working code being maintainable by virtue of the fact that it works, kind of imply that it's perfectly fine for developers to write code without any thought for other people who may have to read it, state explicitly that good algorithms must necessarily equate to good code, and you strongly implied that the best solutions must always be highly optimised ones.

As I have said from the very beginning, and to spell it out for the hard of understanding, I LIKE THE SOLUTION but I wanted to make a wider point about professional code.

You can stay in your myopic world, where the lines of code are all that matter. I prefer developers with a bit of balance, a wider view and an ability to make the right compromises. Oh and I definitely prefer developers that have at least a minimal grasp of how to interact with other humans, a skill you are desperately lacking.

Fair enough. Picking your battles is also a key part of the review process ;)

Then you're just literally "bitching about things that are irrelevant", you know.

(I decided to use blunter words here because, well, comment section are supposed to inform people about the various advantages/disadvantages of a solution, not for people to write pages of rants complaining why they don't like a solution. Literally nobody gives a damn about that, so get over it and accept that you're salty and biased. Doesn't stop people doing this every day though)

Chrus, as I said, I picked a bad example to make a much more general point. However, I stand by the more general idea.

This absolutely would pass code review, because it's a math solution to a math problem. It is not a business/logic problem so it does not require that kind of solution. Should it have a comment that points to the theorem? Absolutely and that's the only review comment it should receive.

Beautiful

Hmmmmm, good algo != good code. Discuss.

Prematured optimization...!? This is non sense...

And it's totally up to you to choose to NOT improve your skills by sticking to "bad algos" believing that's the right choice.

I don't think anyone that pulls out the "premature optimization" card when talking about good code is trying to make much sense.

Anyways, as I've always said before, "complaining about solutions you don't understand/you don't like" is... bad? That's like saying, "I can't break this crypto so it must be unbreakable". Also, since this snippet does what it does exactly, there's nothing about "unmaintainable", "unreadable" or something; they're strawmen since you don't have to maintain or read it. Unless you want to know why it works, but then that's what comments are for, and not the code itself. Code does not, and will not submit to dumb people by dumbifying itself, it doesn't work that way.

I agree about premature optimization in general and that asymptotic complexity doesn't really matter as long as a given task is done in given time.
However, I don't really think that this solution is a case of premature optimization. At least that wasn't my goal, it's just the first thing that came to my mind.
Another thing is that Codewars isn't really a place where people normally comment their code. So it's like: would everyone understand what a solution does--not why it returns what it should, but how it works at lower level? Usually yes. Then if it had some comments, it would probably be ready for production.

And you should absolutely bash code that isn't clear just by reading it. Most of a developers time is spent reading and maintaining code and this aspect should always be foremost unless there is a compelling reason to have to make it more complex.

Absolutely. It's what I would call premature optimisation. In most circumstances the difference between the O(n) and the O(1) will be negligible in real world scenarios because humans can't tell the difference between a nano-second and a micro-second. Both are instant. So all that has been achieved is to obscure something simple behind some maths that most people will have forgotten, and to make all future developers lives maintaining this code harder than it should be. If it turns out that this bit of code is in a performance critical bit of the application then by all means optimise it to O(1) with relevant comments. But don't write code like that as a first attempt. And the problems solved by being able to quickly sum an arithmetic progression are a tiny fraction as compared to the problems that can be solved by consistently using a technology like Linq. So I'll ignore that.