It does, but it's all garbage collected, since the substrings are scoped to the for loop (and just until Integer.parseInt finishes!) There's probably more memory-saving ways of doing this. I like the readability, but definitely not the only way to solve this

That's my style :) Depending on my mood, either - super terse code, or "overly readable". Fun to practice both ways!

It's probably decently expensive space wise, but time wise it calculates everything it needs once, and then it's a happy little cache. I'll take my O(1) time after startup, since math isn't changing anytime soon.

Howdy! Hope all is well :)

In my opinion: Yes! But then again, I wrote it :P

But in a professional environment, code that reads like what you want it to do is SO much easier to understand. Codewars can be fun to try and solve things using "clever" means, but systems that are meant to last need to be readable to be able to be changed and maintained. When you come back to code a week later, a month later, can you understand it? If you're overly clever, it'll be a lot harder.

There is a balance. Your solution has to keep high-level complexity in mind (Big O notation). If a solution can be O(n^2) and legible, or O(n) and be unreadable, make it O(n) and make it as readable as you can!

Fun way to show polymorphism!

Quite fair! Luckily the test cases ignore invalid characters for me.

Not fun performance on a non-RandomAccess List (such as a LinkedList). Due to List.get(index) having a potential O(n), makes this O(n^2)!
Iterators can really improve performance down to O(n)

Fair enough, I guess that's why it's bounded at 999. Very clever, Mouse!

While this seems to be poorly named because it's more fun, there should be SOME indication in the description that named numbers have no hyphens, and there should be no "and"s.

Recommended why? Was there a specific function that offers a better/different solution? If so, happy to hear it.

It depends on how you approach the problem. I've found the Streams in Java to be great for declarative-style programming. I don't have to keep track of a "sum" or "min" variable, or even an "i" counter for the for loop. I just declare the function I want and it's all processed for me by the stream. While it maybe runs slower, such micro-optimizations are outweighed by readability. "Easier to understand" is in the eye of the team working on the code.

Appreciate the feedback!

In Java, Big "B"oolean is only useful if you need it to be an "Object". Using the primitives is a lot more efficient: just true and false instead of Boolean.TRUE and Boolean.FALSE.