Fixed in this fork

nice

you dont even need loops, arithmetic progression sum is (a1+an)*n/2. I guess that exercise is about learning synthax. Otherwise i would be able to do it in straightforward formula in excel without loops.

Much more elegant than my solution.

Nice, even if it appears having issues with cases in which one of the bounces isn't strictly > of window, like this:
assertEquals(1, BouncingBall.bouncingBall(2.0, 0.5, 1.0));

so easy with your solution !

wth!!!!

This solution fails for 3 reasons:

1. should be (l < w): given (3,5) next call is (5, -2), then (-2, 5), then (5, -7), etc. until StackOverflow
2. ignoring issue 1, we don't get to add both 1's as the rectangle reduces (5,3) -> (3,2) -> (2,1) -> (1,1) the last one is null instead of 1
3. answer.addAll(null) throws an exception, this is has the same root cause as number 2, but still worth pointing out

Here is a version that works with my tests :

• Added static calls to check if first call or not
• I am supposing l > w always (for l - w to be positive); so inverted test at l.8
• Testing l > w before anything else
• Ending recursion when the smaller one (w) equals 0 by returning new ArrayList(1) instead of null

Code is as follows: https://www.codewars.com/kata/reviews/55472965761db2bab8000085/groups/623b5f73dff0240001526f40.
Tell me what you think.

Apparently in java8, ArrayList.addAll(null) returns stackoverflow !!
At some point one of the sqInRect will return null so the whole will fail

There is a ton of comments blaming recursion below. But let's stop for a second and look at the code ones again.

Two main drawbacks impact performance here:

1. condition if (l > w) potentially increases the number of calls by two;
2. each method call allocates in memory brand new ArrayList which is pointless.

this is clearly the better contender for best practices imo

Recursion's solution is almost always worse than for-loop statement in efficiency. And every recursion can be replaced by for-loop, but sometimes it's really hard.