touche

Oh, I didn't know about the difference. Thanks for that.

Thanks for the input.

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

The expected return type could be Collection<String> though to allow Lists, Sets and what not... But it's not a big deal.

No, I doubt it would be more efficient.

... :o
mmmh, don't you think...?

• generates duplicates
• consume time to order the set or even compute the hashcodes if you use a classic set

against

• generate every possibility one and only one time
• generate already in correct order.

I guess you need to clear your mind a bit...

The contract is a list to be consistent with the original language too. Don't forget that.

Then I'd just say because:

• either you don't need to sort the answers because the tests will do it for you
• or if the tests wouldn't do it, you still don't need it because it will be more efficient to generate all the possibilities already in order.

;)

It will be better for readability and for DRY sake, rather on efficiency.

It's considered bad practice by many to ever use exceptions for control flow. The expectation is that if you parseInt, it should work, so you test that it will work before hand. However, even in this case, parseInt might fail on an integer that the regex would accept (such as a very large integer), so it might be better to rely on the exception provided by parseInt itself, in order to be more robust.

Nah, just a missinterpretation on your side.

2 cakes are left.
YOU eat 1 cake.
ENEMY now has to skip because he can't chose 1 again (as described in rule 4).
YOU have to eat the last cake (aka, stalemate loss), because you can chose 1 again (as enemy effectively was forced to chose 0)