So this Code Kata has been a big investment. I never dreamed that it would have 7 posts tied to it. It seems fitting that we do this last one to get to 7 and summarize all that we have accomplished.
Come on that just a bunch of self aggrandizement. We don’t need this post.
I actually disagree. The original kata had several goals. I think after this much investment, I should check to make sure we actually solved the goals.
Errors
First in relations to errors. I did not have much in the way of errors. Most of my errors were tied to putting the incrementing in the wrong place.
For instance in day 2 I put the counter++ originally just before the recursive call. I ended up with a set of tests that would not pass. It took about 2 seconds once I ran my integration test to realize the problem but I still had to run them.
Likewise on day 5 I put my counter++ at the top of the call trying to learn from my previous experience and that screwed me. Most of my error time was in day 5 as I worked out the deadlock that stopped my async functions.
Oddly, I don’t think I had a single one off error I caught. Now I am overly relying on the unit tests to prove true in this case. I have not done 1% of the integration testing I would do on a real program. That being said, I would assume the unit test would be excellent at catching one off errors as it is telling the expected result.
Merits
The relative merits of each approach. This is actually something I would not have thought about had I not gone back and reviewed the kata. Day 1 is probable how I would normally solve it. Though I would ditch the foreach loop and use a for loop. Trying to track the index in the foreach was a stupid thing to do. That being said the iterative approach is the most likely thing I would have started coding.
The recursive approach would probably never crossed my mind. I rarely write any recursive functions. In collage, I ended up with a D in C because I got cute on the final test when I used a recursive solution to something that the professor decided should have been iterative. My reward for my inventiveness was my B turning into a D. Losing 20% on 25% of your grade really messes with those letters. Either way, I generally don’t write code like that anymore. In this case, I think all the shifting around and removing things would create more memory demands but I could see it maybe working better with a huge set of data.
Day 3’s LINQ approach was using the wrong tool to solve the problem. In my experience, this is the solution of C# developers. Most slavishly use LINQ. That cause the whole if all you have is a hammer then all the problems in life look like a nail. That being said, it worked. I do think it is mostly clear what is going on in the code. It may have a performance advantage since I know Microsoft has spent a bunch of time working on LINQ.
If my brain is going good then day 4 is my solution. While the iterative is the most likely solution, I would initially come up with, Day 4 is the refactor version. If you remove the null check it is small, clean and elegant. I suspect it also has the best performance as we are using a collections method as the author intended.
Day 5 is well a gigantic pain in the ass. I did run into my first deadlock problem in a very long time. It required the most work to get working. It was also probably the least clean, concise and elegant. I hope I never have to deal with something so bad in the future.
So Day 4 is the production code, Day 5 is the nightmare and I would say day 4 was also the most fun to write. It just came together like magic.
The 5 Techniques
How did I come up with the five techniques I used? First I took the low hanging fruit offered by the author. I took the iterative and recursive. I ditched the functional because that is hardcore academic style of code writing that I have never seen in the wild. So that was two.
Because I am a C# developer, I saw the problem as a nail and whipped out my LINQ hammer. Just because I have a low opinion of C# developers’ dependency on LINQ does not mean that I don’t think of LINQ regularly. Anyway, that secured my third option. The fourth was a response to how much I disliked by Day 3 result. It was my better way.
The fifth and final one came from the reality that I am working on my multi-threading and I used it as a chance to advance that cause. It was simple, I need practice so I am going to crap this square peg into the round hole.
So that wraps up the Code Kata 2, now onward to Code Kata 3. Hopefully it will be as much fun as 2.