it is clever but the readability of it is not that great... the condition and output of if statement is on the same line, i would say is not best practice beacause the author has sacrificed readability for realestate.

Best practices are the generally accepted manner of writing code. Doesn't really matter what that manner is, as long as a lot of people agree on it. The fact that 14 people all wrote this code in almost exactly the same manner makes it a pretty good estimate of what best practices are, at least for the problem at hand.

I disagree with you on the regexp bit. It's a computational efficiency hellhole to do that. It simply wouldn't work well with (for example) parsers, where the order of matches is often very important and implementing a regexp in that way is entirely unfeasible. However, generally when you're writing a parser, you don't write a single regexp, you generate one. I get what you're saying though, and that's one reason named captures were added as a feature to a lot of regexp engines. A quick Google search even tells me that Python (surprisingly not Perl) was the first implementation that included it.

IMO
Best practice is when a code is small, efficient and easy to understand.

When people refactor, they sometimes make the code smaller but a bit unreadable. That's not the best practice.
Sometimes people add unneeded generalisation, that is also not the best practice.

For example a function that returns if a regex pattern contains 3 groups of chars is better done as 3 separate regex tests for each group. Even if that is 3 times more tests, the code will be much easier to read.

I don't really like the term "best practice", as I can't point my finger to what exactly it means. It would be better if you had something to compare this code with. Is it something in particular that you don't like here?

I can't really find a better implementation going through the solutions. Maybe using the variable names shorter, longer would add some readability, but the scope of the problem is so small that maybe being more concise is better.

I agree this is very clever and concise, but is it really best practices?

I think that a hash would work well, but don't get me wrong - I don't think your solution is wrong (I really like it wrapped in a class), it's just that I don't like case statements - they look kinda ugly to me :D

Thanks. What do you suggest in place of the switch? Using a Hash?

I like that this solution used a class. I don't like the switch in interperet...

That's exactly the point, why this solution isn't the best.

Clever! I like it, but is it really best practice? If you are given a large array and the some of the first elements are out of order, you be iterating through the whole array before the function returns false. Wouldn't it be optimal to return early when an out-of-order sequence is detected?

I found it unclear that this only had to be built to handle exactly 3 chained methods, not an arbitrary amount. So for anyone wondering, you only need it to work for Calc.new.number.operator.number. Nothing else.

See the comments below. I think that we need to use integers for the Ruby version. The description is a bit confusing. Still in the process of figuring that out.

I had to submit the final solution multiple times for it to work. This has happened to me on multiple Haskell Katas. I'm not sure if it is this specific Kata or something with the Codewars backend. Anyone have any ideas?